Open dckc opened 5 years ago
As I start more thorough documentation, some of the warts in the API seem worth fixing. For example, h2b and b2h #54 . I'm not sure I like ethereum norms much better.
This is a commit I haven't pushed yet because it doesn't pass the tests:
Hex<T>
-> HexStr<T>
cc @dimworm @JoshOrndorff
I like all those design choices. :+1:
ok, I've got markdown-doctest working for ed25519verify.
It pointed out that the example in the README was out of date. :)
I changed my mind about the API again.
Top level of API TOC now (027aca3) fits in a short list:
I'm inclined to promote the ed25519Verify example up from that function to the RholangCrypto section and weave it into more of a story form.
I wonder about combining RevAddress and SignDeployment into one thing... about REV transactions. Maybe fold Ed25519keyPair in there too.
Status by section as of a6dc377:
RegistryProxy
- TODO (#32)RHOCore
- not doneEd25519keyPair
- not doneThere are still some rough edges around getting the flow types picked up by the documentation system...
But I think this is enough groundwork to finally attack the question of how to use the registry #32 in the RegistryProxy
section. I'm inclined to close this and move on to that one (leaving RHOCore
and Ed25519keyPair
to the someday pile).
I'd like to talk it over with someone... @JoshOrndorff ?
Examples like this suggest the API is getting too "deep":
const aliceAddr = REV.RevAddress.fromPublicKey(Hex.decode(alicePub));
assert.equal(aliceAddr.toString(), '11112cFcjtrjwn7qCDvTLMu5jEvMSBN2qT1sBwQxDP9AyQCVi26xKZ');
Maybe it should be more like...
const aliceAddr = REV.address(alicePub).toString();
... using https://github.com/Widdershin/markdown-doctest