[Feature] Better support for command arguments about jda-utilities HOT 3 CLOSED

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);
}

from jda-utilities.

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.

from jda-utilities.

Closing this for being stale.

from jda-utilities.