Skip to content

Conversation

@rklaehn
Copy link
Collaborator

@rklaehn rklaehn commented Feb 20, 2020

This is just lexicographical byte ordering, which should be very fast
in case of multihashes since they usually differ within the first 8 byte
word.

Ordering is useful to have if you e.g. want to output a set of multihashes
in a deterministic way for debugging/testing purposes. Also, many possible storage engines work using lexicographical byte ordering. And it allows you to use ordering based collections like BTreeSet with multihashes.

This is based on #47 , so should be reviewed once
that is merged.

Copy link
Member

@dignifiedquire dignifiedquire left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense to me

@vmx
Copy link
Member

vmx commented Feb 21, 2020

@rklaehn Could you please rebase this change?

This is just lexicographical byte ordering, which should be very fast
in case of multihashes since they usually differ within the first 8 byte
word.

Ordering is useful to have if you e.g. want to output a set of multihashes
in a deterministic way for debugging/testing purposes.

Also, many possible storage engines work using lexicographical byte ordering.
no need for an explicit instance
@rklaehn
Copy link
Collaborator Author

rklaehn commented Feb 21, 2020

@vmx Done. I also let rust derive the PartialOrd for the MultihashRef, since it is perfectly capable of figuring that out on its own...

@vmx vmx merged commit 7a69337 into multiformats:master Feb 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants