-
Notifications
You must be signed in to change notification settings - Fork 984
Flatten notification enums #4496
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
Conversation
8e90e40 to
93451db
Compare
93451db to
37ab3c5
Compare
37ab3c5 to
4578dea
Compare
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.
Many thanks! It will definitely make #4471 even clearer for @FranciscoTGouveia, so looking forward to landing it :)
| Install(n) => n.level(), | ||
| Utils(n) => n.level(), | ||
| Temp(n) => n.level(), | ||
| ChecksumValid(_) |
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.
The original code (that has been deleted in this PR) seems to be grouping this by notification level first and then by order of variants. Should we do the same with the merged version?
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 intend to delete most of Notification in a next PR, so I don't think there's a lot of value in style tweaks.
We've had 4 different
Notificationenums:dist::notifications::Notificationdist::temp::Notificationutils::notifications::Notificationnotifications::NotificationWhile these carried somewhat different variants (although there was some overlap as well!), the complexity of having these separate types does not seem worth it. (And in fact, the existence of the
Notificationtype itself doesn't seem all that valuable.) Merge all the variants into the top-level type.