Improve OptionHelper methods

[Andre601]

Pull Request

Pull Request Checklist

Please follow the following steps before opening this PR.
PRs that do not complete the checklist will be subject to denial for missing information.

• [x] I have checked the pull request page for upcoming or merged features/bug fixes.
• [x] I have read JDA's contributing guidelines.

Pull Request Information

Check and fill in the blanks for all that apply:

• [ ] My PR fixes a bug, error, or other issue with the library's codebase.
• [x] My PR is for the Commands module of the JDA-Utilities library.
• [ ] My PR creates a new module for the JDA-Utilities library: ______.

Description

Improves the methods within the OptionHelper class as follows:

• Switch from List<OptionMapping> options = event.getOptionsByName(option); to OptionMapping option = event.getOption(key); since JDAs getOption essentially does what the Option Helper did.
  • Also, the return has been updated too and now checks if option is null rather than empty.
• Made optMember always return default value when the command was not executed in a Guild. Just to remove pointless get-calls that only return null.
• Improved documentation to make some info more clear and gave an example use-case in the class' description.

[Andre601]

So... I now added optX(SlashCommandEvent, String) options which return optX(SlashCommandEvent, String, <defValue>) with some specific default values.

For anything nullable is this simply null, for optBoolean is it false and for the numbers (long, double) is it 0 and 0.0 respectively.

I didn't apply any @Contract annotations to the nullables, simply because they seem to not be needed (IntelliJ complains about improper usage of (@Contract("_, _") since it requires a arg -> result or smth...)

If I should change any of the default values, lmk.

[Chew]

I'm half debating having event.getUser() (and whatever else) for the default values if they are in the event. Not sure about others but I'd find falling back to the invoking user more useful than null. Same with MessageChannel I think?

[Andre601]

I'm half debating having event.getUser() (and whatever else) for the default values if they are in the event. Not sure about others but I'd find falling back to the invoking user more useful than null. Same with MessageChannel I think?

Personally, I see it like that null should be returned as it simplifies if checks. With a nullable return value can I simply check if the option is null and do things while with the other I have to compare it with the event user or smth else which I don't think is that nice.

Like, if I want to return an error when the user was not given would I need to call SlashCommandEvent#getUser() just to check if a default value was returned, while with null a simple x == null check can be performed...

Returning null here would signify that the option was either not filled out (in case of an optional... option) or the key was wrong... Either way, for me makes it much more sense to have null returned.

[Chew]

Yeah I suppose that's easier, and more consistent.