Rename Trie.prove to Trie.createProof #120
Comments
Yeah I think some documentation could probably help. |
Deprecation might also be a procedure. We need to get a bit better at managing deprecation changes though, probably by some more systematic tracking strategy on these, maybe along release planning issues or as separate permanent deprecation-topic issues. Currently this is a bit random if things really get removed on subsequent major releases. |
Wow, that makes sense. The function name is indeed misleading. I can easily see code being created as:
so I think it makes sense to move to this new semantic. I also hope that the TypeScript version of MPT can provide living documentation to people in their IDEs. |
Regarding deprecation, I agree we need a systematic approach. We can define a solid organization-level plan that can be coherently reproducible by any of us. |
I agree that I'll be happy to update the documentation and write examples if these proposed changes are included in the v4 release. I did not use the proof method in the MPT tutorial as they weren't required for the things I was trying to explain, but I definitely could add an example or two using createProof if people want. |
ok sounds great I'll get started on this 👍 |
solved with #122 |
I always had problems with "reading" the proof-related functions of MPT (in the sense of: grasp the functionality by seeing the names), see e.g. the examples. For a long time I thought that I am just not getting the whole picture.
Now on a closer look it seems to me that the name of the
Trie.prove
function is just plain wrong, I'll repaste the example code here:prove
is is a noun, in the example above theconst prove
name makes no sense at all, but also when looking at the implementation of Trie.prove one realizes that thisproves
nothing at all but just creates a proof, which can then be used (therefore the double confusion on my side) to prove that an item is contained in the trie by using theTrie.verifyProof
(or - here it would fit better - an imaginaryTrie.prove
) function. All this gets also verified by seeing the intuitively used naming conventions and descriptions in the tests.So I would suggest to rename to:
Does this make sense respectively am I still missing something?
Along I would suggest the following simplifications/changes to the
proof
related API:Old/current:
Suggestion:
It would also be good if these methods could get some doc comments along for signature description.
I would really love to see this integrated in
v4
if all makes sense (at least the first part), think this is really some not-to-underestimate mental blocker on using this.//cc also @gabrocheleau
The text was updated successfully, but these errors were encountered: