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

Changes to the SlashCommandInteractionOptionsProvider #1116

Closed
felldo opened this issue Sep 2, 2022 · 0 comments · Fixed by #1171
Closed

Changes to the SlashCommandInteractionOptionsProvider #1116

felldo opened this issue Sep 2, 2022 · 0 comments · Fixed by #1171
Labels
🔨 breaking-change An issue or pull requests that would be a breaking change improvement An issue which suggests an improvement of an existing feature

Comments

@felldo
Copy link
Member

felldo commented Sep 2, 2022

The SlashCommandInteractionOptionsProvider is an interface that contains methods to get options from a slash command interaction. Both the SlashCommandInteraction and SlashCommandInteractionOption interface implements it to be able to navigate through the options more conveniently.
Currently methods like getOptionLongValueByName only make sense if you are on the last "level" of the command. That means if the current option is a SUB_COMMAND or if the command has no sub command.
Therefore invoking these methods on the following command:
/base group subcommand <arg1>
they will always return an empty optional if you are currently on the base or group level.

To address this issue we should decide what should be done.
On the one side changing the behavior to get the options from SlashCommandInteraction#getArguments and renaming the methods would solve it but the API is not as fluent anymore if you are navigating though the options by yourself. Then if you are on the last level the getOptionLongValueByName methods would be missing. Then it might be a bit weird to call getArgumentLongValueByName although the options of the current option contains the arguments.
On the other side this change is not that bad because there shouldn't be any reason to get the arguments that way if you can call the convenience method getArguments or the new added methods.
Imo the advantages we get by doing this change is bigger than a bit less fluent API

@felldo felldo added improvement An issue which suggests an improvement of an existing feature 🔨 breaking-change An issue or pull requests that would be a breaking change labels Sep 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🔨 breaking-change An issue or pull requests that would be a breaking change improvement An issue which suggests an improvement of an existing feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant