Replies inline
> On Feb 9, 2020, at 6:24 AM, Wiebe-Marten Wijnja <w...@resilia.nl> wrote:
>
> The underlying problem to me seems that in this example `nil` is used both as
> a default to be returned when nothing is found and as an actual value in one
> of the data structures.
I don't think it's the leaf node that we're focused on though. The issue is the
intermediate steps on the path taken through the data structure. If at any
particular step you cannot make the next step, is that an exception or nil? I'd
be happy if we're consistent with either approach, but the problem is that the
current implementation raises if the "next step" is a list it can't find, but
returns nil if it's a map it can't find.
> Instead, I think that rather than treating this symptom (frustration at
> seemingly inconsistent behavior),
> we should tackle the underlying cause (the behavior being consistent but
> confusing):
If you're saying the existing behavior is consistent, then that is the core of
what I'm disagreeing with.
>
> We e.g. could introduce something named e.g. `fetch_in` that makes a clear
> distinction between values that are not in the nested collection vs values
> (like 'nil') that are there:
>
> ```
>
> iex> users = %{"john" => %{age: 27}, "meg" => %{age: 23}
> iex> fetch_in(users, ["unknown", :age])
> :error
>
> iex> %{"items" => ["desired_value"]} |> fetch_in(["items", Access.at(0)])
> {:ok, "desired_value"}
>
> # This is the important difference
> # It is clear here that `nil` is there rather than the default being returned.
> iex> %{"items" => nil} |> fetch_in(["items"])
> {:ok, nil}
>
> # Therefore, it now makes sense to the programmer
> # that an error is raised here
> iex> %{"items" => nil} |> fetch_in(["items", Access.at(0)])
> ** (RuntimeError) Access.at/1 expected a list, got: nil
> (elixir) lib/access.ex:663: Access.at/4
>
> ```
Your fetch_in approach still treats list traversals as a special case. Why does
that last example not return :error as your first example does? In both cases
it could not follow the path.
> As for actually solving Greg's practical problem at hand: If you want to
> treat explicit `nil`'s the same way as 'the key does not exist',
> then what about removing any fields that point to a `nil` value before
> performing your '`get_in` and friends'-based validation?
I know how I can solve it in my own codebase, but this suggestion won't solve
it. I'm afraid I haven't explained the situation well enough. If get_in cannot
navigate the path to the value specified, I don't want it to raise. I'd prefer
it return nil, but :error would also be acceptable (or an optional `default`
parameter). In my situation the inability to navigate the path should be the
same as navigating the path successfully and finding an explicit `nil` at the
end.
-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/665C5A29-28DB-4430-92F5-0C0299BCC094%40gmail.com.
