Command API

Sponge Sponge Development
35
  1. We will be registering commands dynamically most likely. Convention > configuration
  2. Intake is extremely modular:
    1. CommandCallable is an interface that (essentially) takes callable.execute(sender, arguments).
    2. Dispatcher (an interface) is also a CommandCallable, but it lets you register commands on it, so callable.execute(sender, "addmember") would call an “addmember” subcommand.
    3. If you want a “command manager,” you just use a Dispatcher at the top.
    4. If you want subcommands, then you use a Dispatcher somewhere below (commandManager.register(dispatcher, "region", "rg")).
    5. The annotation code builds CommandCallables. You basically give ParametricBuilder your .class file and it will give you a List<CommandCallable>. manager.registerCommands(YourClass.class) does not exist, which means the annotation implementation is 100% separate.
    6. Some of you want to use annotated methods to register commands but don’t want parametric injection (i.e. @Command void myCommand(Sender sender, CommandContext args)). The annotation library supports this 100% too because to it, all it is doing is injecting a Sender object and the arguments.
    7. Intake supports switches, flags, and quote handling (/mycommand -f -w world "hi there"). However, this is also 100% optional because Intake only gives you a String for arguments. (However, the annotation code does mandate this parser).
  3. If you use annotations, it still passes a context object underneath. Annotations are an abstraction on top of the simpler command code.

So basically Intake does everything* while letting you use almost nothing.

*besides one-command-per-class annotated commands.

8 Likes