[commands v3] Make Mechanism an interface

[Daniel1464]

Since there is no longer a requirement for Subsystems/Mechanisms to be registered to the command scheduler via a register() call, Mechanism can be changed to an interface instead to allow for more flexible inheritance structures.

Specifically, this would allow compatibility with CTRE swerve(which previously required implementing Subsystem so that it could extend CTRE's base class).

[KangarooKoala]

Why not put a setDefaultCommand(idle()); into the DummyMechanism constructor?

[Daniel1464]

Since the default command of Mechanism is now null instead of idle(), and since DummyMechanism is just supposed to be a Mechanism itself, I don't think having it implicitly do this is the best. I could be wrong tho

[KangarooKoala]

👍 Yeah, that seems fair. I guess another option would be to have a decorator that sets the default command:

public DummyMechanism withIdleDefaultCommand() {
  setDefaultCommand(idle());
  return this;
}

// Then we can do e.g. mechanisms.add(new DummyMechanism("System " + i, m_scheduler).withIdleDefaultCommand());

This is just for illustrative purposes- Exact signature (return type and name) can vary.
This also might be overkill, anyways- Calling setDefaultCommand() for the different instances is annoying but ultimately not that bad. I'm fine with whatever you decide (which could just be marking this as resolved).

[KangarooKoala]

Any concerns about losing this default toString()? I'm not familiar enough with commands v3 to know if people may print a Mechanism or a collection of Mechanisms. (e.g., someone prints cmd.requirements() when debugging)
There also isn't much of a difference because the default toString() also contains the class's name, but the @xxxxxx might be confusing.
It's not a huge deal, but I just want to double check.

[DeltaDizzy]

I had initially (when the idea to convert first came up) suggested a split to Mechanism (interface) and MechanismBase a la v2 for this reason, though I don't feel super strongly about it (and in fact don't really like "MechanismBase" as a name).

In practice I don't think many teams give their subsystems names different from their classes, but it could show up in the case of having multiple copies of a subsystem on the robot (which I actually have done before!). If it is deemed an uncommon case it is probably fine to just tell teams to manually override it in their subsystem if they want to change the string representation (maybe include that in the Mechanism template used in the project generator?).

[KangarooKoala]

I agree that teams wanting subsystems to have names other than the class names can override getName() (even with the slight amount of plumbing to have separate names for difference instances).

My main concern is about the default toString() including the @xxxxxx stuff at the end, which could be confusing for rookies. Again, it probably isn't an issue since they probably won't see that toString() output, but I want to make sure that we have proper justification.

[SamCarlberg]

getName() is used in telemetry, but many inexperienced programmers will just print objects to System.out.println for quick and dirty debugging, and that will use the default toString() implementations. I don't think that's generally an issue, since most subsystems only have a single instance, and those that have multiple should override getName() anyway to have unique names for each instance

[KangarooKoala]

If the only way people will see toString() is from directly printing the Mechanism objects (or a collection of Mechanism objects), then yeah it's probably fine. (Just wanted to double-check that there wasn't any other way people might see the toString().)

[Daniel1464]

yeah, the idea was to let ppl override getName() instead.