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)
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)
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.