-
Notifications
You must be signed in to change notification settings - Fork 3
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
Make the API more generic/trait-aware #29
Comments
@UARTman good point, let's do it |
@UARTman any progress here? |
@yegor256 Thanks for reminding me! I'll draft the PR with the changes I've been able to make so far today evening or tomorrow. |
Implemented `Eq` trait, designating that every two `Hex`es can be compared. Removed a string equality hack from `PartialEq` implementation, removing unnecessary allocations.
@yegor256 I've done the first PR. However, there's still some ideas I'd like to look into, like a proper |
@yegor256 Most of the other code wasn't as obviously in need of trait implementations, since most of our types aren't thin wrappers over bytes. However, I'll take a closer look at whether there are places that will benefit from using slices or borrows. Also, a question: should I implement more |
@UARTman yes, let's handle |
@UARTman what's up with this job, not yet complete? |
Right now
Hex
API is written without much regard for traits. For example, it has multiplefrom_
methods that use the same code relying onFrom
trait, as well as afrom_str
method that conflicts with theFromStr
trait.These can be either replaced or augmented with code that's generic over traits. This will make
Hex
a bit more capable and idiomatic.Then, if making
Hex
more generic/trait-aware is a success, we can do the same to other types where necessary.The text was updated successfully, but these errors were encountered: