We are open to a mechanism that makes this possible but I am afraid we
haven't found one yet. path_expression doesn't help, because again, it
makes you think it is a general mechanism but it applies only to get_in and
not the other functions. All other functions do not work with nil - so even
in terms of inconsistency I am more inclined to think get_in should always
fail on nil and not the opposite.
I am sorry but I cannot provide further guidance on this because I am
myself not sure what the solution is. If others have suggestions, we will
be glad to hear them.
On Sun, Feb 9, 2020 at 2:18 AM Greg Vaughn <gvau...@gmail.com> wrote:
> On Feb 8, 2020, at 6:34 PM, José Valim <jose.va...@dashbit.co> wrote:
> >
> > Also, I should have asked this sooner, but can't the complex path that
> you are writing be easily expressed with pattern matching?
>
> Can your use cases use pattern matching too?
>
> Since you asked, my primary use of Kernel.get_in is when I have untrusted
> json at the edge of my system. I have multiple sources that have to be
> mapped to a common internal struct/schema. The first step is to look for
> the equivalent of all the keys we care about and create a map with known
> key names. Then we go through an Ecto changeset for validation and further
> processing.
>
> I look for, let's guess, about 15 fields from each of these json payloads.
> I'd have to pattern match 15 times with an if statement, because if I have
> 14 real values but the path through the json of one of them is not present,
> I still want to go through the Ecto validation logic because that one key
> that is missing might not be critical to our business logic. Since that
> logic is in the next innermost layer, I don't wish to code it into this
> outer layer that just tries to pull what it can out of the untrusted json.
>
> I am open to naming concerns. I do rather like the #{name} vs. #{name}!
> approach to highlight the inconsistency in the existing get_in behavior. I
> think we could call it `path_expression` which is a term used in object
> oriented databases and in other languages, though it seems long. You said
> to take modifying `get_in` off the table from consideration, but I think it
> leads naturally to `get_in` vs. `get_in!`.
>
> I can accept if the decision of the core team is that my use case is an
> outlier and I should write my own module to handle this. I'd still hate
> leaving the inconsistent behavior of get_in in the standard library, but
> I'll adapt and move on.
>
> -Greg Vaughn
>
> --
> 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 elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/B090C168-E959-484B-ADB1-A81AB177D732%40gmail.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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JH%3DjjhdWOkj8xErUvOPqwn4FYUvCXJcaRe4og4pUQwRA%40mail.gmail.com.
