Skip to content
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

Express auto resize functionality as a type? #17

Open
marshallpierce opened this issue Feb 19, 2017 · 2 comments
Open

Express auto resize functionality as a type? #17

marshallpierce opened this issue Feb 19, 2017 · 2 comments

Comments

@marshallpierce
Copy link
Collaborator

While working on #10 I'm ending up with error options that can only occur if resize is disabled. This is unfortunate as it means that someone using resize will now have to handle error variants that won't ever occur at runtime.

The way that auto resize interacts with the contracts of the methods is a little regrettable to begin with. I wonder if there's a way we could reflect this difference in the type system rather than with comments here and there describing what will or won't happen when auto resize is enabled. Maybe a trait with associated types for errors and implementations for both auto resize and plain histograms? Almost all the code could be re-used between the two, I think, with just some different error enums to give each style a very precise error mapping.

@jonhoo
Copy link
Collaborator

jonhoo commented Feb 19, 2017

Mmm, I like that idea. I'm not sure we could actually use an enum for this, since Rust doesn't currently consider enum variants separate types (rust-lang/rfcs#1450), but we could probably get away with using two unit structs, and impl the relevant methods only for one or the other.

My biggest concern would be that the place where we need separate impls would be for, say, the record, methods. However, there are also a bunch of other methods that also use the record methods, and they would need to have different impls too. You're probably right that we might be able to factor this out in a clever way though.

@marshallpierce
Copy link
Collaborator Author

Another wrinkle to think about: auto-resize is not serialized (and therefore not deserialized), which makes me lean a little more towards making auto resize a wrapper or something like that so that a deserialized histogram really could be 100% identical to its original version.

marshallpierce pushed a commit to marshallpierce/hdrsample that referenced this issue Apr 13, 2017
This makes it now safe to use on 16-bit systems, with one small
exception in V2DeflateSerializer.

This necessitated adding a few error types to things that used to
overflow. Various other little cleanups performed while following
the logic around.

Fixes HdrHistogram#17.
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

No branches or pull requests

2 participants