Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
trie: avoid endianness conversion in GetTreeKey #140
trie: avoid endianness conversion in GetTreeKey #140
Changes from all commits
42306ea
b1f131f
a5ef57e
619bcfb
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mentioning something that might be off-topic for this PR, but I wonder if it might be interesting at some point to unify
Commitment()
andCommit()
.Mostly because
Commitment()
panics if there's no value in the cache, and as a client, it might not be entirely obvious when that invariant holds.So, something like a unique
Commit()
method that checks the cache, and whenever some action touches that node, it sets that tonil
again, so on the nextCommit()
that is re-computed.I feel you intentionally created these
Commit()
andCommitment()
APIs, so there is probably a good reason I can be missing. Maybe it's useful to access the previous commitment value even after touching the node.I'm just surfacing some personal uncertainty I had while deciding between
Commit()
andCommitment()
since it wasn't entirely obvious and could produce a panic.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It used to be the same, but at some point I found it useful to distinguish between a function that enforces the recomputation of the commitment and one that just returns it if it's available and panics if it's not.
I have a big refactor in the pipe that reduces the need for this distinction, and it will make sense to do what you say when it's merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took the liberty to improve this test a bit to enforce an expected value.
I did this in the first commit of the PR before changing
GetTreeKey(...)
so I could have an anchor source of truth to know if the improved implementation was generating the same output as before. The branch generates thef42f9...
value before the improvement.This test still passing makes me more comfortable about the change (and future ones, if any). I don't know if you have some way to gain more confidence in some other branch or similar; it never hurts. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah that makes sense, thank you for that.