Access on structs with typed members

In a project I’m working in, I have to create a boatload of different structs, each containing a list of different types of objects. Think XML with types. The values cannot be set directly on fields because order must be preserved, so there is no explicit type spec on the struct (it has one field that contains a kwlist with the children)

So we are implementing Access on them, to be able to get lenses on them, but I would like the user of these type to not have to know beforehand what type should be put in each child.

What would be the natural way to expose to the user a “blueprint” of the correct struct for a key?

Can some of the callbacks for Access expose an empty struct of the correct type instead of nil?

Is it reasonable for the user to expect that put_in and related functions do initialize intermediate objects when needed? (In the style of mkdir -p)

Thanks for your opinions and suggestions.

Some examples will help a lot, want to post some?

Here is some (writing from memory with a phone keyboard):

defmodule A do
  defstruct values: []

  @element name: "a", type: A, min_occurs: 0
  @element name: "b", type: B, max_occurs: 5
  @element name: "c", type: C

  # implementations of Access and Enumerable

  def fetch(a, key) when is_atom(key) do
    case Keyword.get(a.values, key, :no) do
      :no -> :error
      found -> {:ok, found}
    end
  end

  # more implementations when key is {atom, index} to retrieve a child after the first
end

thing_a = %A{values: [
  b: %B{…},
  b: %B{…},
  c: %C{…},
]
# suppose :some is an element of C

put_in(thing_a, [:a, :c, :some], "value")

In my mind, the user shouldn’t know the specific type of C, the above code should produce (up to reordering, with is out of scope here)

%A{values: [
  a: %A{values: [c: %{values: [some: "value"]}]},
  b: %B{…},
  b: %B{…},
  c: %C{…},
]

You can observe that the top level A and the nested C are created automatically.

I think I can achieve this behaviour but I’m not sure whether it breaks some contract and whether there are better ways to allow the user to put values creating the intermediate steps as needed.

This involves using functions-as-keys in the path list that know what empty struct to supply when one is needed.

Access.keys/2 does this for Maps and structs. Use its implementation

as a blueprint for what you need to do in your particular case.

Very interesting, I haven’t thought about it. So the user instead of providing just the key path, would provide something like

put_in(thing_a, [
  MyAccess.key_or_create(:a),
  MyAccess.key_or_create(:c),
  …
], "value")

and the functions will be created based on some protocol that I need to define and implement?

Makes total sense, I did not feel 100% comfortable in returning non-nils on missing keys.

1 Like

Example:

defmodule Nav do
  def a,
    do: key(:a, [])

  def c,
    do: key(:c, [])

  def some,
    do: key(:some, [])

  defp key(key, default) do
    fn
      :get, data, next ->
        next.(Keyword.get(data, key, default))

      :get_and_update, data, next ->
        value = Keyword.get(data, key, default)

      case next.(value) do
        {old, update} ->
          {old, Keyword.put(data, key, update)}

        :pop ->
          {value, Keyword.delete(data, key)}
      end
    end
  end
end

thing = []
path = [Nav.a(), Nav.c(), Nav.some()]
new_thing = put_in(thing, path, "value")
IO.puts("#{inspect(new_thing)}")

update = &{&1, "more " <> &1}
{old_value, more_thing} = get_and_update_in(new_thing, path, update)
IO.puts("#{inspect(old_value)} #{inspect(more_thing)}")

result = get_in(more_thing, path)
IO.puts("#{inspect(result)}")

{deleted_value, pop_thing} = pop_in(more_thing, path)
IO.puts("#{inspect(deleted_value)} #{inspect(pop_thing)}")
$ elixir nav.exs
[a: [c: [some: "value"]]]
"value" [a: [c: [some: "more value"]]]
"more value"
"more value" [a: [c: []]]
2 Likes