Example of implementing Access protocol (behaviour?) in Struct

fireproofsocks

I stumbled across the desire to want to use get_in while accessing deeply nested parts of a custom struct while needing to provide a default value. I could make a simple defp function to achieve this, but I wanted to see how to handle it using the Access protocol, so I tried something like this:

get_in(my_struct, [:x, Access.key(:y, "my_default)])

Where my struct was shaped something like

%MyStruct{x: %{y: "My Value"}}
# or maybe 
%MyStruct{x: %{}}

This results in an error:

** (UndefinedFunctionError) function MyStruct.fetch/2 is undefined (MyStruct does not implement the Access behaviour)

I have 2 followup questions to this:

Is there an example somewhere in some library that demonstrates how to implement the Access behaviour?
I’ve read somewhere that structs don’t implement this behaviour for performance reasons – what considerations should be made before implementing the behavior in a struct?

Thanks as always!

10 comments

#protocols #behaviours #access

1 2691 10

2025-03-31 09:35:16 UTC

First 10 of 10 Posts

NobbZ

Not performance I’d say… Semantic reasons. It doesn’t make sense for all structs.

Also let’s take a fictive set which implements access and returns either true or false, depending on if the value is a member.

The struct itself has only a single field, which shall not be made accessible, but instead access is just a Map.get(s.m, value, false).

I’m not aware of any examples though, but perhaps you can find something in elixir code base for maps or keywordlists.

Post #1

kip

ex_cldr Core Team

I think you’ll find this will do the trick:

iex> get_in(my_struct, [Access.key(:x, Access.key(:y, "my_default"))])
%{y: "My Value"}

You can wrap struct keys in Access.key/2 if required without implementing the whole Access protocol.

Post #2

fireproofsocks

That looks promising… however, it seems to return not the value for :y (or its default), but instead, the entire map stored at :x

Post #3

kip

ex_cldr Core Team

Wasn’t quite sure what you were after. Probably you wanted:

iex> my_struct = %MyStruct{x: %{y: "this thing"}}
%MyStruct{x: %{y: "this thing"}}
iex> get_in(my_struct, [Access.key(:x), Access.key(:y, "my_default")])
"this thing"

Note that since :x is just a map you can do the following if you don’t need to supply a default (which you shouldn’t have to so since this is about a struct:

iex> get_in(my_struct, [Access.key(:x), :y])                          
"this thing"

Post #4

fireproofsocks

That works! I think I tried a dozen things that were close to that. Thank you!

Post #5

msante

I came here looking for a simple way to implement Access behaviour by all structs, but I agree with @NobbZ, it doesn’t make sense to do it for all structs.
So I thought of a simpler solution, just ‘unstructure’ those structs where I need to use get_in to access them deeply.

I made this little function:

  def destructuring(struct) when is_struct(struct) do
    struct |> Map.from_struct() |> destructuring
  end
  def destructuring(list) when is_list(list) do
    list |> Enum.map(fn v ->
      destructuring(v)
    end)
  end
  def destructuring(map) when is_map(map) do
    map |> Map.keys() |> Enum.reduce(%{}, fn (k,acc) ->
      Map.put(acc, k, destructuring(map[k]))
    end)
  end
  def destructuring(val), do: val

so when I need it I can do:

iex> my_struct |> destructuring() |> get_in([:x, :y, :z])

Post #6

nwjlyons

Elixir 1.17 added get_in/1 (Note the arity 1) which works with structs.

get_in(my_struct.x.y) || "my_default"

Post #7

msante

I’m new to elixir, but wouldn’t this be the same as doing this?

my_struct.x.y || "my_default"

Apart from this, I wonder how I could take advantage of get_in/1 in the case that the list of keys has to be generated dynamically based on certain logic?

Post #8

frankdugan3

~~No, because my_struct.x.y would raise an error if my_struct or x were nil. get_in/1 provides nil-safe access, similar to Javascript’s myObject?.x?.y.~~

Sorry, just realized I didn’t account for the logical ||. So for this specific case, both should do the same thing.

Post #9