-
-
Notifications
You must be signed in to change notification settings - Fork 130
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
refactor(model, util, validate)!: Convert CommandOptionChoice
to a struct with value variants
#2081
refactor(model, util, validate)!: Convert CommandOptionChoice
to a struct with value variants
#2081
Conversation
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.
Could be nice to have this for name_localizations
as well?
I was thinking about my implementation and think it can be improved. What are your thoughts on a breaking change to make struct CommandOptionChoice {
pub name: String,
pub name_localizations: Option<HashMap<String, String>>,
pub value: CommandOptionChoiceValue,
}
enum CommandOptionChoiceValue {
String(String),
Integer(i64),
Number(f64),
} This way if/when new choice variants are added (or possibly new fields) we don't need to update name() and name_localization() getters. |
I think that's an even better change! |
2d6b4e8
to
5851575
Compare
name()
getter to CommandOptionChoice
CommandOptionChoice
to a struct with value variants
CommandOptionChoice
to a struct with value variantsCommandOptionChoice
to a struct with value variants
5851575
to
245784c
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.
A very nice improvement!
One thing I noticed in the builder API is that we silently discard localizations if the choice is not found. It might be better to panic to alert users of their buggy code. Something like:
/// ...
/// # Panics
///
/// Panics if the choice is not set.
/// ...
#[track_caller]
pub fn choice_localizations<K: Into<String>, V: Into<String>>(
mut self,
choice_name: &str,
name_localizations: impl IntoIterator<Item = (K, V)>,
) -> Self {
let choice = self
.0
.choices
.as_mut()
.expect("choices are set")
.iter_mut()
.find(
|choice| matches!(choice, CommandOptionChoice{ name, value: CommandOptionChoiceValue::Integer(_), ..} if name == choice_name),
).expect("choice is set");
// ...
…odel/feat/choice-name-getter
CommandOptionChoice
to a struct with value variantsCommandOptionChoice
to a struct with value variants
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, I pushed some small changes that I did not felt warranted a second review round
This PR refactors
CommandOptionChoice
to be a struct rather than an enum. The main reasoning behind this has to do with the fact that all choice variants have fields in common (name
andname_localizations
). Accessing these fields currently requires the user to exhaustively match an enum variant. With these changes, the shared fields can be accessed directly and instead variance is introduced by using an enum type on thevalue
field.