How will the Command API work?

[Squawkers13]

Continuing the discussion from Command API:

@sk89q

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.

I’m just curious what that stuff means.

How would you go about using this theoretical API?

[FerusGrim]

Just recently stopped lurking, so I wasn’t apart of the initial conversation. But it appears as though the Command API will (as it states) be more modular in that, with Bukkit, you could only catch the first command.

Bukkit: /example

// Main class, extends JavaPlugin
public void onEnable() {
    getCommand("example").setExecutor(new ExampleCommand(this));
}

// ExampleCommand.java
public class ExampleCommand implements CommandExecutor {
    private final Main plugin;

    public ExampleCommand(Main plugin) {
        this.plugin = plugin;
    }

    @Override
    public void onCommand(CommandSender sender, Command cmd, String label, String[] args) {
        if (args.length > 0) {
            // Some OOP method of setting up subcommands, or a messy if/else map.
        }
    }
}

Whereas, with Sponge, it appears as though there will be a built-in registration for sub-commands.

I don’t know this theoretical system well enough to give a decent example code, so you might just want to ignore the mess I’m about to spew.

@Command
public void onCommand(Sender sender, CommandContext args) {
    // I have no knowledge of what CommandContext is, so... I guess I'll just pretend it's String[], for now.
    if (args.length > 0) {
        if (args[0].equals("sub")) {
            callable.execute(sender, "sub");
        }
    }
}

EDIT: Also, as demonstrated above, it also appears as though you won’t actually have to register the main command. Just annote @Command above a method in a valid class. But, again, working with code I haven’t been able to see myself, yet.

EDIT2: And yes, the constructor which passes an instance of the main class in the Bukkit example is useless. Blame it on habitual programming.