-
Notifications
You must be signed in to change notification settings - Fork 1
Null variant labels #110
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
Null variant labels #110
Conversation
Since we are no longer using it as a label, we do not need a recognizable special value here. Instead, just use hash of an empty string, so we can remove the special casing in code.
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.
I like the approach but I think letting the user to potentially provide custom label with null-variant
is opening the door to bugs and implementation errors.
I would far prefer to take a more "direct" approach.
If you declare a null variant. Either I ignore you custom variant requested or you immediately get a validation error.
I think we would gain to be more drastic. If it's a guarantee then it's a guarantee - the user should not have to / and should not be allowed to potentially do otherwise
You can merge once you're happy with the changes - I'm happy with the implementation (aside of being more drastic in the approach) |
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.
LGTM after the changes
Signed-off-by: Michał Górny <[email protected]>
Remove `NULL_VARIANT_HASH` since it resembles magic constant too much. In the few places where we need it, either call hash directly, or get it from VariantDescription. Signed-off-by: Michał Górny <[email protected]>
get_variant_label()
helper for convenience.null
label for null variants.sha256("")
.