[Feature] Better support for command arguments

pindab0ter commented 4 years ago

Issue

Issue Checklist

Please follow the following steps before opening this issue.
Issues that do not complete the checklist may be closed without any help.

[x] I have checked for similar issues on the issue tracker.
[x] I have updated to the latest version of JDA-Utilities.
[x] I have checked the branches or the maintainers' PRs for upcoming features/bug fixes.

The issue tracker is reserved for issues, errors, and feature requests related to JDA-Utilities, and not questions and other requests for help.

For examples, check out the examples module or the list of JDA-Utilities projects.

For questions join the official JDA discord server and ask them in our #jda-utilities channel.

For general programming questions, visit StackOverflow.

Issue Information

Check all that apply:

[x] This is a bug report about an error, issue, or bug in JDA-Utilities.
[ ] I have been able to consistently reproduce this bug.
[x] This is a feature request for the JDA-Utilities library.

This issue tracker does not assist or handle issues with the JDA library.
For JDA related issues, visit the JDA issue tracker and open an issue there.

Description

Commands often make use of arguments, sometimes even multiple. Currently the Commands module doesn't support arguments beyond providing a maybe null args.

What I would like is support for the following features:

Providing args as a list of strings, which would be the current args but split by spaces
An optional minimum and maximum amount of required arguments for commands that require them (for example, a command could require one or two arguments, replying with feedback when not enough or too many arguments are provided)
Support for flags, enabling things like -c for compact output for mobile users

I took inspiration from command line frameworks like oclif's https://oclif.io/docs/args and https://oclif.io/docs/flags.

jagrosh commented 4 years ago

Providing args as a list of strings, which would be the current args but split by spaces

It's one line to put String[] splitArgs = args.split("\\s+"); into your command, and we don't want to do this all the time, as that's a large overhead for a niche thing.

An optional minimum and maximum amount of required arguments for commands that require them (for example, a command could require one or two arguments, replying with feedback when not enough or too many arguments are provided)

I can see merit in this. However, you could just write your own class that extends Command that does this.

Support for flags, enabling things like -c for compact output for mobile users

While flags are easy to understand for programmers/developers, the majority of users (from my experience developing bots used by hundreds of thousands of servers) don't understand flags, so I don't think we'd want this to be the default behavior of jda-utils. Additionally, if you want custom arguments parsing (like flags), I'm sure there are libraries out there that you could use that take in a string (from CommandEvent#getArgs()) and will do the parsing for you.

Overall, I'm not sure what benefit there would be to adding this suggestion in, as you can already make a class that extends Command and plug in whatever arguments-parsing library or custom code that you want.

public abstract class SplitArgsCommand extends Command
{
  protected int numArgs = 0; // 0 for no limit to number of args
  protected String split = "\\s+";

  @Override
  public void execute(CommandEvent event)
  {
    String[] args = numArgs == 0 ? event.getArgs().split(split) : event.getArgs().split(split, numArgs);
    if(numArgs != 0 && args.length < numArgs)
    {
      event.replyError("Too few arguments provided. Expected " + numArgs + " arguments!");
      return;
    }
    doCommand(event, args);
  }

  abstract void doCommand(CommandEvent event, String[] args);
}

pindab0ter commented 4 years ago

My aim is to reduce boilerplate code that I see returning in almost every command I write. Extending the Command class would do just that. I looked through some other projects and noticed a few that could benefit from this. It's up to you whether you want to extend your project with this functionality. If you don't I'll happily use your suggested approach and maybe even send you a pull request down the line.

pindab0ter commented 2 years ago

Closing this for being stale.

JDA-Applications / JDA-Utilities