I am so impressed with how long the background processes in your brain live, José :-)
You don't need my review, but the commit looks :thumbsup: to me. -Greg Vaughn > On Apr 2, 2021, at 11:41 AM, José Valim <[email protected]> wrote: > > After coming to this issue a couple times, I believe we should accept this > proposal. > > My arguments were: > > 1. This proposal won't work for update_in/pop_in. My counter-argument, as of > now, is that this is already true given that get_in(nil[:foo][:bar]) returns > nil but update_in(nil[:foo][:bar], & &1) raises. > > 2. This proposal would remove an API that raises on nil. My counter argument, > as of now, is that if you don't want to raise on nils, you likely won't use > get_in anyway. Instead you will do map["foo"]["bar"] |> Enum.map. > > I plan to submit this to master soon, to be included on v1.13. > > On Monday, July 6, 2020 at 5:46:31 PM UTC+2 [email protected] wrote: > I have not thought about this in a while. I don't immediately see those new > functions as something I'd use. They push extra burden on the client > programmer to know all the corner cases and protect from them. I always > envisioned `get_in` as something like searching an html document via a css > selector. It never raises, even if the document is empty. It either finds > matching nodes or it does not. > > I learned from earlier in this thread that is not the mental model the core > team has for `get_in`. I ended up creating a small library to meet my needs > (https://hex.pm/packages/path_express > <https://hex.pm/packages/path_express>). > > -Greg > > > On Jul 6, 2020, at 5:54 AM, José Valim <[email protected] > > <applewebdata://55F9F5B7-F366-44F8-8D3B-0D36AABA5C9E>> wrote: > > > > Resurrecting this old-thread. Greg, what if we had a Access.if_nil([]) that > > would put an empty list if there is a nil value? We could also have > > Access.on_nil(:error), which effectively halts. > > > > A bit verbose but it will give you control exactly what to do and when, > > without coupling to the current functions. > > > > -- > > 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] > > <applewebdata://55F9F5B7-F366-44F8-8D3B-0D36AABA5C9E>. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/elixir-lang-core/36580c49-f276-4512-a2aa-da7ecb7daf60o%40googlegroups.com > > > > <https://groups.google.com/d/msgid/elixir-lang-core/36580c49-f276-4512-a2aa-da7ecb7daf60o%40googlegroups.com>. > > > > > -- > 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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/4389ddde-4aff-4002-b5a6-bd519d693065n%40googlegroups.com > > <https://groups.google.com/d/msgid/elixir-lang-core/4389ddde-4aff-4002-b5a6-bd519d693065n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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/F4A89745-9CB7-4C12-B0AB-01B6C099C676%40gmail.com.
