GitLab

We now have both MapIterator and ListIterator interfaces.
Both return key-value (or index-value) pairs, rather than just keys.

List iterators may seem a tad redundant: you just loop over the length,
right?  Well, sure.  But there's one place a list iterator shines:
selecting only a subset of elements.  And indeed, we'll be doing
exactly that in the traversal/selector package; therefore, we
definitely need list iterators.

We might want keys-only iterators again in the future, but at present,
I'm deferring that.  It's definitely true that we should have iterators
returning values as a core feature, since they're likely to be more
efficiently supportable than "random" access (especially when we get to
some Advanced Layout data systems), so we'll implement those first.

Additionally, note that MapIterator now returns a Node for the key.
This is to account for that fact that when using the schema system and
typed nodes, map keys can be more *specific* types.  Such nodes are
still required to be kind==ReprKind_String, but string might not be
their *preferred* native format (think: tuples with serialized to be
delimiter-separated strings); we need to account for that.
(MapBuilder.Insert method already takes a Node parameter for similar
reasons: so it can take *typed* nodes.  Node.TraverseField accepting
a plain string is the oddball out here, and should be rectified.)
Signed-off-by: Eric Myhre <hash@exultant.us>

Having a function called "Kind" return a "ReprKind" was inconsistent.

Also, we want to introduce a "Kind" method on `typed.Node` in the future.

No logical content to this change: you can safely refactor with sed.
Signed-off-by: Eric Myhre <hash@exultant.us>

(... offically.  Lots of docs have probably already been stating that
this is there.  Now it actually... is.)
Signed-off-by: Eric Myhre <hash@exultant.us>

This has been deprecated and replaced by the NodeBuilder system
for a good while now; time to scrape it into the dustbin completely.

Tests that were primarily on the mutable node system itself also
drop, so, this is a *very* large delete diff.

A few other tests used MutableNode just incidentally, and those are
quick fixed to use NodeBuilder.
Signed-off-by: Eric Myhre <hash@exultant.us>

As detailed in comments a few commits ago, this is part of a big, big
roll towards keeping linking details far enough off to one side that
one can actually use most of the IPLD system without forming an
explicit compile-time dependency on any linking features (until, of
course, one uses the linking features).

This is a surprisingly small diff, because... well, because most of
the *interesting* features around linking simply weren't implemented
yet, and at this point everything that is has already been isolated
in the new cidlink and related encoding packages.
"CID" was *already* just a semantic placeholder that meant "eh, link".
Signed-off-by: Eric Myhre <hash@exultant.us>

An "immediate" rather than generative function is also available;
the docs contain caveats.

At the moment, these distinctions are a bit forced, but we want to be
ready for when we start getting truly huge maps where the generative
usage actually *matters* for either memory reasons, latency reasons,
or both.

Separated Length rather than trying to pull double-duty the Keys
method; the previous combination was just utterly silly.

The implementations in the bind package are stubs; that package is
going to take a lot of work, and so the focus is going to be entirely
on keeping the 'free' package viable; and we'll revisit bind and such
when there's more dev time budget.
Signed-off-by: Eric Myhre <hash@exultant.us>

Signed-off-by: Eric Myhre <hash@exultant.us>

It should return an error explicitly.

A pair of "(nil, nil)" reponses would also be an unambiguous option for
representing an absent member, but seems more likely to create pitfalls
than save a significant amount of code for callers.
Signed-off-by: Eric Myhre <hash@exultant.us>

You could now readily rig up the ipldfree.Node implementation to a
refmt cbor.TokenSink, for example, and go to town.  (At the moment,
doing so is left as an exercise to the reader.  We'll make that a
smooth built-in/one-word function at some point, but I'm not yet sure
exactly how that should look, so it's deferred for now.)

While working on this, a lot of other things are cooking on simmer:
I'm churning repeatedly over a lot of thoughts about A) API semantics
in general, B) how to cache CIDs of nodes, and C) how to memoize
serializations / reduce memcopies during partial tree updates...
And (unsurprisingly) I keep coming back to the conclusion that the API
for dang near everything should be immutable at heart in order to
keep things sane.  The problem is figuring out how to pursue this
A) efficiently, B) in tandem with reasonably low-friction nativeness
(i.e. I want autocompletion in a standard golang editor to be as useful
as possible!), and C) given an (as yet) lack of good builder or
mutation-applier patterns.  ipldbind was meant to be a solution to the
majority of the B and C issues there, but that rubs smack against the
grain of "let's be immutable" in golang >:/  So... a rock and a hard
place, in short.
Signed-off-by: Eric Myhre <hash@exultant.us>

ipldfree and ipldbound and fluent and all the interfaces now have all
the isNull methods, asBytes, setBytes, etc.  (Previously this was a
little swiss-cheesy.)

SMOP.
Signed-off-by: Eric Myhre <hash@exultant.us>

Fairly sure this is going to come up in our handling of typed nodes
(and may also be relevant to some of the REVIEW-todo comments about
sparseness of arrays; haven't yet fully considered).
Signed-off-by: Eric Myhre <hash@exultant.us>

This will be for the active path -- if we also follow through on the
idea of having a just-in-time checked Node wrapper, a lot of these
checks might end up duplicated.  We'll DRY that up when we get there.

Doing accumulation of errors.  Might get loud.  We can come back and
and early-halt parameters or other accumulation strategies later.

Added IsNull predicate to core Node interface.

Going to want enumerated error categories here for sure, but punting
on that until we get more examples of what all the errors *are*; then
I'll come back and tear all this 'fmt.Errorf' nonsense back out.
Signed-off-by: Eric Myhre <hash@exultant.us>

And ReprKind moves from the typed package to the ipld main package.
It's hard to get too much done without the standardization of ReprKind.

Between the Kind() and Keys() methods, it should now be possible to
perform traversals of unknown nodes.

This diff just worries about implementing all the Kind() methods.
Keys() has some additional questions to handle (namely, map ordering?).
Signed-off-by: Eric Myhre <hash@exultant.us>

(Mostly; all the scalars work; the composites are todo's.)

Heading in the direction of being able to construct stuff for testing.
Almost there.
Signed-off-by: Eric Myhre <hash@exultant.us>

That subject has more to do with SerializableNode.  Which also might
not be the name we end up with for that.  ID'able Node?  LinkableNode?
Signed-off-by: Eric Myhre <hash@exultant.us>

Finally got the bind and free impls on the same page.

Surprisingly, the bind node can work without being a ptr itself.
I'm not sure if that'll last, but let's try to roll with it.
If we *can* keep that property, it might reduce GC impact in a pretty
significant way.

Added a 'fluent' package.  It's just a twinkle in my eye so far, but it
might represent the nicest way through all the discussed issues.
Nodes shouldn't have to be panicful; and users shouldn't have to do all
error handling manually either.  A package full of fluent interfaces
that know what's going on seems to be the only way to get both.
But we'll see how this shakes out.  Maybe typeful traversers will
make the whole thing end up more coreward than being relegated to a
helper package.  I have no idea.
Signed-off-by: Eric Myhre <hash@exultant.us>

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>

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!