Improve implementation of command data

[MinnDevelopment]

Pull Request Etiquette

• [x] I have checked the PRs for upcoming features/bug fixes.
• [x] I have read the contributing guidelines.

Changes

• [x] Internal code
• [ ] Library interface (affecting end-user code)
• [x] Documentation
• [ ] Other: _____

Closes Issue: NaN

Description

This moves the serialization of options into toData(), which removes the need to reconstruct them for getters. Additionally, I've added some more constants to replace the magic numbers in checks.

[MinnDevelopment]

I've added methods to allow removing options/subcommands/groups via conditions:

command.removeOptions(o -> o.isRequired());

This can be useful when updating commands or using some kind of template system. For example:

SlashCommandData command = SlashCommandData.fromData(json); // json which has options set
command.removeOptions(v -> true); // remove options, we only need name/description

[DenuxPlays]

Any updates on this?

[RedPanda4552]

Curious - I see the same 25 limit for options being used for subcommands here. Is the 25 subcommand limit a limit of JDA, or Discord? I recall in the past Discord's API docs did mention a limit of 25 subcommand groups and 25 subcommands. Mysteriously, that has disappeared and all that remains are the limits of 25 options and 25 choices per option. I for one naively hope that Discord did scrub the 25 subcommand limit (hard to explain, using config/runtime generated commands and lots of them) - does anyone happen to know if that limit is still in place and perhaps just not written down on their API docs now? Personally I'd like to see the subcommand and subcommand group limits lifted but if it's still there and Discord just removed the mention of it, then that'd be too bad.

[MinnDevelopment]

In the API, subcommands are equivalent to options, thus they use the same limit.

[RedPanda4552]

In the API, subcommands are equivalent to options, thus they use the same limit.

Well that's unfortunate. Explains things though, thanks!