Witchcraft or one of its dependencies does implement Traversal. There was a previous discussion on this list about Empty as well, which could be used to implement traversable with Collectable. But I only mentioned traverse for curiosity. I think all of them would be outside of scope for core. :)
On Tue, Jun 25, 2019 at 21:10 Johanna Larsson <[email protected]> wrote: > Ah, my version only updates the value, it doesn't expose the key in any > way, so keys would always be preserved. Basically, the way that the list > version doesn't modify order, just values. > > Traverse does sound interesting though! Do you know if any work has been > done in that direction? > > On Tuesday, June 25, 2019 at 8:53:43 PM UTC+2, José Valim wrote: >> >> 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/28d028b7-374f-487a-b141-6a2c39f4dff1%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/28d028b7-374f-487a-b141-6a2c39f4dff1%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D -- 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/CAGnRm4JFmQDEGTFEZor-MHNM8Qm6ABR4zL%3DvsfS6G3GmNdj%2BZg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
