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.va...@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 <prag...@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-core+unsubscr...@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-core+unsubscr...@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-core+unsubscr...@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.
