wip: prototyping what hamt amending might look like.

[warpfork]

More for discussion than anything else -- not final functional code.

I started with the idea of a func (b *Builder) StartWith(n ipld.Node) (ipld.MapAssembler, error) method -- in other words, something on the type that implements NodeAssembler which has a fairly standard signature that we could make feature-detactable through a standard interface -- and just tried to see how that would go.

I think this probably does a large amount of what we'd want.

We could combine this with some kind of ipld.AmendMap(newMem NodeAssembler, basis Node) (MapAssembler, error) method in the main IPLD packages (now that we've done go-ipld-prime#228 and released that in v0.12.0, especially), which will feature-detect this function, or, fall back onto doing a dumb copy and returning an assembler you can continue with in the semantically same way. This would make the "amend" concept usable universally, but also work efficiently when we have a function like this one implemented.

There's tricky bits relating to verifying whether any are actually matching the existing structure you try to modify, but these are incidentals of this hamt implementation and whether it serializes all its parameters, how we decide to verify that, etc. Not relevant to the concept of interface generalization, if we're looking for what patterns can be extracted here.

[willscott]

My immediate question is: if this becomes a method we think of as part of "the core ipld mutable interface", won't that interface end up really big?
There are lots of ways we'll eventually need to support mutation. I don't know if we have a great way to balance efficiency / generalization, but if we go this way it's going to be at least several times larger than the current interface, which seems... totally overwhelming.

[warpfork]

We absolutely do not put this in the core ipld mutable interface. I repeat: This method would not go in NodeAssembler. Triple repeat: we are not extending NodeAssembler in any way, because yes, that would be sweepingly painful.

Feature detection. Those words appear in the initial post repeatedly for a reason.

[warpfork]

Being able to start putting high level operations like "append plz" as functions that work on data (possibly with feature-detection, but always with fallbacks) -- and thus be be able to introduce features and fastpaths without growing the core interfaces -- was the major driving reason behind go-ipld-prime#228. (The marshal/unmarshal functions happened to be the first thing we did after that, but these kind of additions will be the real prize.)