Give Command an additional protected constructor to enable a new command definition pattern with improved syntactic sugar

[cwm9cwm9]

Command helpers are great until you need per-instance state, at which point you usually make a new class. To keep the interface consistent, you might then add a class factory for the new class, paralleling the return of instantiated helper classes.

I'd like to propose a new pattern for the writing of new commands that mimics and improves upon the syntactic sugar of the helper classes.

All that is required is to give Command a new constructor overload:

  protected Command(Subsystem... requirements) {
    this();
    addRequirements(requirements);
  }

Once this is done, Command becomes cleanly extendable via anonymous classes, like this:

    public Command cmdSomeCommand() {
        return new Command(this) {
            private double newVariable;
            @Override public void initialize() { newVariable=0; }
        }.withName("myNewCommand");
    }

This pattern allows users to add new fields and override exactly the methods they wish in the same way they would when extending CommandBase, while simultaneously allowing the immediate instantiation of the class in the exact way Helper classes currently do.

An additional advantage of this pattern is that it eliminates the mixed use of

    Command command1 = cmdSomeCommand();
    Command command2 = new SomeCommand2();

which can happen when users don't implement a class factory.

[KangarooKoala]

Command helpers are great until you need per-instance state, at which point you usually make a new class.

I'd like to point out that instead of storing the state in a new class, you can put it in the method, where it will be captured:

    public Command cmdSomeCommand() {
        // Primitive types can't be changed if they're captured, but we can modify the value of an
        // array or object if we don't change the reference to point to somewhere else
        double[] variable = { 0.0 };
        return this.runOnce(() -> variable[0] = 0)
            .andThen( /* do stuff with variable[0] */ )
            .withName("myNewCommand");
    }

Adding a constructor overload to let subclasses specify requirements might still be a nice quality of life feature, though.

[cwm9cwm9]

Understood, but part of the syntactic sugar I am after is to avoid the lambda capture since it requires the variable be final or effectively final. It's nice to be able to use simple natives so you don't have to carry the extra [0] around.

[KangarooKoala]

Not to get too sidetracked because I think we're still in agreement that this would be a good thing to add to WPILib, but another thing to consider when picking what personally to use is that it can be beneficial to consistently use the command factories and decorators instead of mixing them with anonymous classes.

Again, 100% agree that adding a constructor overload to let subclasses specify requirements is something that should be added to WPILib- I just wanted to provide some food for thought in terms of personal use.

[cwm9cwm9]

You're probably right to say that mixing them in one statement can be a bit much. I believe there's a setName() that can be used in place of .withName. But AFAIK on Command itself there's no .withRequirements?