Move Transform method to root package.
Upon a good night's sleep and reexamining the situation, it's extremely
clear that this function is *not* a fluent thing at all. (Duh; look at
the Node types.)
A non-fluent Transform method has tons of virtue. In many cases, we
might not actually need the fluent.Node helper features at all when
using Transform: since all of the intermediate error handling to
traverse to the reachedNode is already handled, that's half the battle;
and whether or we need to fight the ease-of-use battle on the interior
function is... *it depends*: if we use (codegen'd) native types, those
already address a lot of the error handling; fluent.Node can also be
used on the inside, but it's simply not needed in all cases.
We'll come back to the subject of writing the fluent equivalent later;
some example usage development is needed first so we know how to make
something that's actually helpful.
It will, of course, mostly be a wrapper; the interesting question is
whether a fluent.Transform function should use a fluent.Node either,
since this will make it harder to compose (unless we make fluent.Node
still embed ipld.Node?)... ahem. As I said. We'll come back to that.
One more quick comment about this relocation: I'm a little tepid about
putting the Transform method in the main package, because that really
puts it on-screen quite in the forefront. If it's just Transform and
Traverse, maybe this is fine; but we end up implementing a large suite
of optics methods, this will become cluttery. So, potentially this
will move to another sub-package again if that becomes an issue. (But
it still wouldn't be the fluent package.)
Signed-off-by: Eric Myhre <hash@exultant.us>
Showing
fluent/traverse.go
deleted
100644 → 0
Please register or sign in to comment