GitLab

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

Most important things first!  To follow this refactor:

```
sed s/TraverseField/LookupString/g
sed s/TraverseIndex/LookupIndex/g
```

It is *literally* a sed-refactor in complexity.

---

Now, details.

This has been pending for a while, and there is some discussion in
https://github.com/ipld/go-ipld-prime/issues/22 .

In short, "Traversal" seemed like a mouthful;
"Field" was always a misnomer here;
and we've discovered several other methods that we *should* have
in the area as well, which necessitated a thought about placement.

In this commit, only the renames are applied, but you can also see
the outlines of two new methods in the Node interface, as comments.
These will be added in future commits.
Signed-off-by: Eric Myhre <hash@exultant.us>

The comment in the ipld.Node type about IsUndefined has been there
quite a while; today we're finally using it.

With this set of changes, the generated code for structs now compiles
successfully again: the Undef and Null thunks are both used there.

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

Fields in these structs are now named.  Embedding is reserved for
things that are very explicitly supposed to carry their methods along.

At some earlier point, I embedded the Type field in some of the
generate structs because it saved me a few keystrokes in refactoring
template strings.  This was not important.

Today I learned: if you have embeddings which cause a name to be
shadowed -- as the generateKindedRejections_String.Type field
could shadow the generateKindString.Type field, for example -- if those
resolve "neutrally" (I don't know if there's a better technical term
for this), then... in that case, the templating system will be like
"yeah, fine, whatev", and it works.  If you give one of those two
fields a *separate type*, the templating system will now reject it as
if no field of that name can be found.

I encountered this while working on the generator for structs (which I
*swear* I will commit any second now, when I stop finding prerequisite
yaks to shave -- there have been many) and trying to use a more
specialized TypeStruct instead of the Type interface.  Whee.

I get the logic of this.  The error message could be better.

Anyway: even though it technically didn't affect generateString (yet),
making the change here for consistency with what's to come
(including specializing the field even though there's currently no
actual need for it).

This isn't a net negative size diff yet, but it certainly will have
that effect momentarily when we add a generator for another kind.
More importantly, it reduces the set of functions in the real
generator file to *just* the relevant ones.

We'll almost certainly extend this to cover the NodeBuilder half of
things as well, later; I just haven't gotten there yet.