GitLab

And add a bunch of type-specific ones for helpfulness.

But immediately re-reviewing this further.  What we've done here is
handle leafs very oddly, because it would seem to avoid unnecessary
wrapping on the leaf nodes.  But the result seems to be much uglier
code than it needs to be, and implies that we've got all sorts of
additional special cases required to either handle or reject binds
of primitive-kind fields.  And that seems... maybe not a great trade.
Signed-off-by: Eric Myhre <hash@exultant.us>

Note: I am not very pleased with how many deps this core and simple
data type has.  These are basically all for the hashing, and very, very
little actual hashing code at that, and I really wish the rule about
"a little vendoring is better than a little dependency" would be
applied here -- pulling in x/crypto and x/sys so that I can use a
type that's *a wrapper around string* is thoroughly ridiculous.
Signed-off-by: Eric Myhre <hash@exultant.us>

Some comments on the interface as well.  Almost certain that traversal
should be pulled off the node interface itself.
Signed-off-by: Eric Myhre <hash@exultant.us>

This has been sitting on my hard drive quite a while already, so I
decided to clean it up juuuust enough that it compiles so I can push
it.  But as you can see, there's a LOT of TODOs dangling here.

I'm not at all still sure those comments about "root node" in the
interface are going to stand up to scrutiny over time.  There's
definitely going to be some distinction between "Node we're traversing"
and "Node we are putting in a serialized block of bytes and can
think it's reasonable to address by hash", but figuring out the best
ergonomics of that is probably going to take a while.

I'm going to start on another simpler just-backed-by-maps-n-stuff Node
impl before going deeper with this one, because I suspect it'll make
tests easier to write, which will then make this whole pile of
reflection easier to test down the road as well.
Signed-off-by: Eric Myhre <hash@exultant.us>

Hopefully if we come up with a good way to flip one node impl into another,
we'll be able to come up with an easy interface for "this is referencing
an in-memory structure type of mine, but hashed as CBOR native standard".

We'll see if this is a good idea or not.  It's either a newer, cleaner,
lessons-learned set of libraries for using IPLD; or, it'll turn into a
"lesson-learned" itself and we'll fold the learnings back into the
existing libraries.  Time will tell!