That's a good question. To me, Access is mostly the backend that is used
for the brackets plus get_in/update_in/pop_in. It is not primarily meant to
be invoked directly, unless you truly need to write a lazy fetch that works
against keywords and maps. Which do not sound very common in practice.
I also think the keywords vs maps vs structs is a common confusion point
and I am curious to see if the type system will give us more affordances
around those cases and better guidelines.
On Thu, Aug 8, 2024 at 5:08 PM Tobias Pfeiffer <prag...@gmail.com> wrote:
> You're correct, my thing with all of this is just that we already have
> these functions when working with the specific data types. To me it makes
> sense to have the same function available when using the module that
> (mostly) wraps these. The added benefit isn't just readability imo, but
> also familiarity with the function and that it'd then also work with other
> types that implement Access, as [] doesn't work on structs.
>
> On Thu, Aug 1, 2024 at 12:00 PM Jay Rogov <rogovyaros...@gmail.com> wrote:
>
>> I think it can pretty much be substituted with `data[key] ||
>> expensive_fun()`, can it not? (apart from the case when key actually points
>> to `nil` value)
>>
>> The only benefit of this added function I see is improved readability
>> when piping, but it's still possible to do without it:
>> ```
>> iex(1)> data = %{a: 3}
>> %{a: 3}
>> iex(2)> data[:a]
>> 3
>> iex(3)> |> Kernel.||(:rand.uniform)
>> 3
>> iex(4)> data[:b]
>> nil
>> iex(5)> |> Kernel.||(:rand.uniform)
>> 0.764306455162276
>> ```
>>
>> On Wednesday 31 July 2024 at 8:28:04 pm UTC+2 José Valim wrote:
>>
>>> I see. It seems to be a narrow use case for now, so I think
>>> Access.fetch/2 is the way to go until we get more evidence that many folks
>>> need something similar. My impression is that the direct Access functions
>>> are not that commonly used in general. :)
>>>
>>> On Wed, Jul 31, 2024 at 8:23 PM Tobias Pfeiffer <pra...@gmail.com>
>>> wrote:
>>>
>>>> Heyo José,
>>>>
>>>> in most cases it's just a helper method with optional args - which I
>>>> like to keep in a way that users of it can user either a map or keyword
>>>> args.
>>>>
>>>> In this particular case it was this helper for tests:
>>>>
>>>> @supply_tag 744_306
>>>> def my_helper(opts \\ []) do
>>>> query_string = Keyword.get_lazy(opts, :query_string, &
>>>> build_query_string/0)
>>>> supply_tag = Access.get(opts, :supply_tag, @supply_tag)
>>>> ip = Access.get(opts, :ip, "68.235.110.20")
>>>>
>>>> "https://some.url#{supply_tag}#{query_string}&ip=#{ip}";
>>>> end
>>>>
>>>> build_query_string/0 takes some time but not a lot - but it could also
>>>> take more time aka the classical get_lazy/3 use case.
>>>>
>>>> Using Keyword.get_lazy/3 here works but limits callers to use keywords
>>>> (or do a Map to Keyword conversion) which limits the usefulness of `Access`
>>>> to me - as I tend to prefer to use it when both maps and keyword lists seem
>>>> acceptable.
>>>>
>>>> Cheers + thanks,
>>>> Tobi
>>>> On Wed, Jul 31, 2024 at 8:39 AM José Valim <jose....@dashbit.co> wrote:
>>>>
>>>>> Hi Tobi, can you provide some context of how it would be used, code
>>>>> wise? Which problem are you facing?
>>>>>
>>>>> On Wed, Jul 31, 2024 at 08:10 Tobias Pfeiffer <pra...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello beloved core team,
>>>>>>
>>>>>> TLDR; Should we have Access.get_lazy/3 ?
>>>>>>
>>>>>> As usual I'm sure there is some reason why this doesn't exist yet but
>>>>>> I don't know so here is the question/proposal:
>>>>>>
>>>>>> We have Map.get_lazy/3 and Keyword.get_lazy/3 - they're amazing and
>>>>>> helpful. Access basically encapsulates the 2 and I generally use it
>>>>>> where I
>>>>>> can to allow both Keywords and Maps - most commonly when I deal with
>>>>>> options. It doesn't have get_lazy/3 though, which sometimes makes me fall
>>>>>> back to either Map or Keyword (or wrap it myself).
>>>>>>
>>>>>> Using Access.fetch/2 it should also be easy to implement.
>>>>>>
>>>>>> So, would a PR implementing Access.get_lazy/3 be considered?
>>>>>>
>>>>>> Thanks!
>>>>>> Tobi
>>>>>>
>>>>>> --
>>>>>> 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-co...@googlegroups.com.
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAG3Z5YQYuv8SF81vs8UNhtpGN3wA0NHgH1yFhixuwoQmV2S8eQ%40mail.gmail.com
>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAG3Z5YQYuv8SF81vs8UNhtpGN3wA0NHgH1yFhixuwoQmV2S8eQ%40mail.gmail.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 elixir-lang-co...@googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4L6popY-tMX54mKh3kc_cbmYRa7G7G0Em64ZPUoZEX6Lw%40mail.gmail.com
>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4L6popY-tMX54mKh3kc_cbmYRa7G7G0Em64ZPUoZEX6Lw%40mail.gmail.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 elixir-lang-co...@googlegroups.com.
>>>>
>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAG3Z5YTOA%2Buditq5jfHETFNanUwT_fXsnjt-S%2BnekqCJcp_20A%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAG3Z5YTOA%2Buditq5jfHETFNanUwT_fXsnjt-S%2BnekqCJcp_20A%40mail.gmail.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 elixir-lang-core+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/813bfaf3-059f-4890-b82e-2af35c7720f4n%40googlegroups.com
>> <https://groups.google.com/d/msgid/elixir-lang-core/813bfaf3-059f-4890-b82e-2af35c7720f4n%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 elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/CAG3Z5YTTCO0n7OyvEQU-OS9KVAat%3DnNpysJm0y7sxLAwm6-Z3w%40mail.gmail.com
> <https://groups.google.com/d/msgid/elixir-lang-core/CAG3Z5YTTCO0n7OyvEQU-OS9KVAat%3DnNpysJm0y7sxLAwm6-Z3w%40mail.gmail.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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BdjRby4HwoFQ-F16g_rO%3DqVowtYJJQK8p8nLF3dMCzBQ%40mail.gmail.com.
