-
Notifications
You must be signed in to change notification settings - Fork 190
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
API Refactoring #612
Comments
Thanks for the insights @rrichardson! I'd be keen to see what an alternative greenfield API might end up looking like. I'd also be keen to see what real benefits that API offers over the current organization. The current design is that:
This is a bit of a less obvious division of responsibilities as your proposed API, but is similar conceptually. I'm not currently expecting us to make any breaking changes to the library anytime in the foreseeable future, but also wouldn't want to discourage alternatives that are simply better, so if there's real material benefits we should keep an open mind. |
The most practical immediate benefit of reducing the number of features down from 15 to 4 would be that two of the CI jobs will work again (they run their container out of disk space with the powerset of features (I'm sure there are easier ways to address this :) )) I think the API would not change much, I think, but the salient points are: The UUID versions should no longer be locked by features, however, some of the necessary bits to build some versions would need to be supplied by the user if they opt out of the necessary components. The best way I can think of to offer a unified interface over the variety of required units is with a builder API. Also, I think the context should be required for either counters/sequences or rng's. I would prefer that I manage the state that such things requires. My preference for the timestamp is just the opposite. I'd prefer that the API abstract that away from me. |
That's a fair observation. The cost of confident builds with so many possible combinations is a burden from feature flag creep I've hit in other projects too. One of the reasons we have the features is that some users really want to avoid pulling in additional package dependencies wherever possible, and for a fundamental utility it seemed reasonable to continue to try cater to them. |
I’ve been running back over things in #625 and I definitely see your point. I’ve tried to paper over some of the issues a bit, but we could do a lot better. |
Motivation
The UUID Crate has grow organically over the last 5 years. It's seen many new features, and groups of features added, and new uuid version support has been added, where convenient. The Rust ecosystem has evolved significantly in that time. The implementations in the crate have sort of evolved in different directions, there is the Builder, which has functions which are general, and it has functions which are specific to a single UUID version (without mentioning that version's name, see ::from_random_bytes)).
There are about 15 features in this crate (if you include the newest versions). IMO, that number should be closer to 4.
As a result of its growths and offshoots in various areas, the crate is a bit of a mess, with many inconsistencies and some characteristics that make it look a bit dated.
Solution
I propose we refactor the crate in preparation for a new major release.
The basic idea would be this:
uuid::v1::new(...)
If people are OK with this basic arrangement, then I will start working on an RFC.
The text was updated successfully, but these errors were encountered: