This makes Cid implement https://golang.org/pkg/encoding/#BinaryMarshaler
which is used by go-codec to decide if things know how to serialize themselves
(currently we need do manual wrapping for anything containing a CID).
Since I was at it, I did the TextMarshaling one too.
Right now this is mostly this is to document the behavior of interface-keyed
maps. I suspect some of those caveats might be non-obvious to a lot of folks.
Using interfaces as a map's key type can cause some things that were otherwise
compile-time checks to be pushed off into runtime checks instead.
This is a pretty major "caveat emptor" if you use interface-keyed maps.
Added back in some of the parser methods. (These were previously named "Cast"
and I think that's silly and wrong so I fixed it.)
Functions are named overly-literally with their type (e.g. ParseCidString and
ParseCidStruct rather than ParseCid or even just Parse) because for this
research package I don't want to bother with many sub-packages. (Maybe I'll
regret this, but at the moment it seems simpler to hold back on sub-packages.)
Functions that produce Cids are literal with their return types, as well.
Part of the purpose of this research package is going to be to concretely
benchmark exactly how much performance overhead there is to using interfaces
(which will likely cause a lot of boxing and unboxing in practice) -- since we
want to explore where this boxing happens and how much it costs, it's important
that none of our basic implementation functions do the boxing!
The entire set of codec enums came along in this commit. Ah well; they would
have eventually anyway, I guess. But it's interesting to note the only thing
that dragged them along so far is the reference to 'DagProtobuf' when
constructing v0 CIDs; otherwise, this enum is quite unused here.
It's been discussed in several issues and PRs already that we might want to
explore various ways of implementing CIDs for maximum performance and
ease-of-use because they show up extremely often. Current CIDs are pointers,
which generally speaking means you can't get one without a malloc; and also,
they're not particularly well-suited for use in map keys.
This branch is to attempt to consolidate all the proposals so far -- and do so
in a single branch which can be checked out and contains all the proposals at
once, because this will make it easy to do benchmarks and compare all of the
various ways we could implement this in one place (and also easier for humans
to track what the latest of each proposal is, since they're all in one place).
To start with: a Cid implementation backed by a string; and matching interface.
(I'm also taking this opportunity to be as minimalistic as possible in what
I port over into these experimental new Cid implementations. This might not
last; but as long as all this work is to be done, it's a more convenient time
than usual to see what can be stripped down and still get work done.)
More to come.
