On Feb 8, 2020, at 6:34 PM, José Valim <[email protected]> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/B090C168-E959-484B-ADB1-A81AB177D732%40gmail.com.
