Access Behaviour on Structs

Questions / Help
1

To simplify some tasks at work, I wrote and published this package yesterday. It’s a simple macro that enables Access behaviour on structs.

So, while I know this goes directly against core design decisions, it makes it extremely simple to perform deeply nested gets/updates on complex structs. This is something I could see myself using on every major project from now on.

I’ve found relatively little discussion about it, so I’m wondering, have I done something dirty?

8 Likes
2

I think core’s design decision in this regard is twofold:

  • The compile-time guarantees of struct.field access should be strongly encouraged over the runtime struct[:field] form
  • The creator of the struct might have a different vision for what Access might mean for their data-structure

This is why it’s not a part of core—I don’t think that means that it should be avoided within your own structs, though, especially if they nest other data-structures you intend for your struct’s users to interact with manually.

An example of the second point might be a Conn struct that represents key/value access to an external system, like redis or an API. It’s going to want to define Access for itself, but with radically different intentions than exposing its actual literal fields.

4 Likes
3

I ended up here from trying to ask a new question: Where can one find details on the reasoning behind why Structs in Elixir do not implement the Access behaviour?

As a first, rookie take on this, I started with something like

  # `Struct`s don't implement the `Access` behaviour.
  #
  # TODO: Similar patterns exist throughout the codebase. Re-evaluate if
  #       `get_in_struct/2` and `put_in_struct/3` are the desired approach.
  #
  # Allow for something similar to `put_in` for `Struct`.
  @spec put_in_struct(struct(), nonempty_list(atom()), term()) :: struct()
  defp put_in_struct(struct, location, value) do
    locator = Enum.map(location, &Access.key/1)
    put_in(struct, locator, value)
  end

  # Allow for something similar to `get_in` for `Struct`.
  @spec get_in_struct(struct(), nonempty_list(atom())) :: term()
  defp get_in_struct(struct, location) do
    locator = Enum.map(location, &Access.key/1)
    get_in(struct, locator)
  end

Digging deeper, my current understanding is that this approach is not Elixir-idiomatic. Instead, it is the Access behaviour that “should” be implemented.

Is this understanding aligned with the Elixir community’s best practices?

If so, since this link is out of date*, where can one find an example of implementing the Access behaviour for Structs?

1 Like
4

I believe the approach documented here is now the way to do this.

5

You can use put_in and get_in on structs like shown by Dogbert in Elixir: best practice to extract data from nested structs on Stackoverflow.

5 Likes
6

Looks like it is for protocols, not behaviours. I think I will use struct_access to avoid copy/pasting:

@behaviour Access
defdelegate get(v, key, default), to: Map
defdelegate fetch(v, key), to: Map
defdelegate get_and_update(v, key, func), to: Map
defdelegate pop(v, key), to: Map

Note that the pop function might better be implemented as below to silently ignore the request to delete the key. Or we might want to raise.

def pop(v, key), do: {v[key], v}
4 Likes
7

You can try macros maybe.

import Maybe
event = %Event{user: %User{name: "John"}}
maybe(event.user.name) # => "John"

It’s a slightly modified version of maybe from phoenix_base by Daniel Berkompas

2 Likes