-
Notifications
You must be signed in to change notification settings - Fork 159
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
v3 Hamt update #982
v3 Hamt update #982
Conversation
} else { | ||
// Can't overwrite, return None and false that the Node was not modified. | ||
return Ok((None, false)); | ||
} |
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.
@austinabell Isn't this where you were going to address that additional case you mentioned on our review call? Also, can you describe why that came to mind, so I can understand better?
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.
So the point I was thinking through is not relevant to consensus, because the go implementation does not return the previous value. However, thinking through it a third time, I think that in this case a few lines above should be modified a bit.
The case is on set (overwrite = true) and the values are equal, should the value being passed in be returned back. Although it seems weird internally to do this, it would match a HashMap
functionality by returning the value that existed. The difference would be that we are not swapping the values, and assuming PartialEq is implemented correctly. I am going to switch it to returning the value that existed, to match a HashMap
implementation, but open to just returning the value passed in. This operation should be super quick in every case so I think it's the best decision
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.
Also, just to be clear, the only case which this would have unintended behaviour is when PartialEq
doesn't match serialized bytes equality AND
this was the only value changed, the parent roots won't be updated. Definitely nothing to worry about, but worth keeping in mind that PartialEq
must match bytes equality to interop in every case with go.
Summary of changes
Changes introduced in this pull request:
!go-interop
flag)Tested against https://github.com/austinabell/go-hamt-ipld/tree/rust/testing
Will wait on #981 and add another method to the API before opening PR for review
Reference issue to close (if applicable)
Closes #959
Other information and links