Re: duplicates. You could do something like "update_in [:foo, &all_map/3], ..." and that changes the keys in a way you have duplicate keys, which would be lot.
The code snippet look neat though. I guess the more general version of it would be a traverse/3 function powered by a Traverse protocol that knows to enumerate and put things back together. Then it would be able to work with binaries, maps, lists, etc. *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D On Tue, Jun 25, 2019 at 8:46 PM Johanna Larsson < [email protected]> wrote: > Fair enough! I'm curious what you mean by duplicate keys, that wouldn't > happen for a map, would it? > > To give more context, I use my version the same as `Access.all/0`: > > update_in( > data, > ["hosts", &all_map/3, "events", &all_map/3], > updater > ) > > and the code is pretty much the same, just turn the map into a list before > using the same code as `Access.all/0` and then back to map. > > On Tuesday, June 25, 2019 at 6:30:11 PM UTC+2, José Valim wrote: >> >> I don't think there is anything that makes it hard to implement, except >> the conceptual issues that happen from such feature. If there are duplicate >> keys, which one wins? The other concern is that the Access API is also >> mostly specific to one data type, so we would need a new function for maps >> and I am not sure if it is worth it. It may be best to roll your own. :) >> >> >> *José Valim* >> www.plataformatec.com.br >> Skype: jv.ptec >> Founder and Director of R&D >> >> >> On Tue, Jun 25, 2019 at 6:26 PM Johanna Larsson <[email protected]> >> wrote: >> >>> I recently found the need for, and implemented, a version of >>> `Access.all/0` that handles maps. The implementation is very similar to the >>> one for lists, so I'm curious if anyone has any insight into why there's no >>> built-in version for maps. If there's something I'm missing that makes it >>> difficult to implement in a nice way that doesn't have weird corner cases, >>> or if there just hasn't been a perceived need for it. >>> >>> I tried searching this mailing list and the Github repo but I wasn't >>> able to spot anything related to "Access.all". >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "elixir-lang-core" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/88ae7e74-5bbb-4b3e-9eaf-cc1344a114e5%40googlegroups.com >>> <https://groups.google.com/d/msgid/elixir-lang-core/88ae7e74-5bbb-4b3e-9eaf-cc1344a114e5%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/3598b84f-26a9-4430-b4c3-f449b4174f63%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/3598b84f-26a9-4430-b4c3-f449b4174f63%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BEAwgqDtpRCyrB8LtssLbU4N_vMFrei8JwZeF1OguTLw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
