TalonFXControlMode unnecessary

[Redrield]

When skimming the new API for the 2020 season, I'm struggling to figure out why TalonFXControlMode and TalonFXFeedbackDevice are necessary. Since TalonFX is a subclass of BaseMotorController, it still functions with the old enums, and internally the new enums are simply converted and then delegate to the functions in BaseMotorController anyways.

[ozrien]

TalonFXFeedbackDevice is for Talon-FX. It contains only the enums supported by the product. It self-documents what the capabilities that hardware can do. Same with TalonSRXFeedbackDevice. Notice the FX enum does not have analog, but does have integrated-sensor.

However if you need to write software that works with all Talon* classes, you can use the general FeedBackDevice enum class, which allows you to do this, BUT does not provide compile-time checking to ensure you don't select something unsupported in your hardware device.

The same is true with control modes. ControlMode will hold all possible values, including values that may not be supported in all hardware products. TalonFXControlMode values are guaranteed to work on that particular product. It just appears strange now because they happen to be the same. I suspect this will change in the future, at which point we may add a TalonSRXControlMode (which doesn't back-break anything since ControlMode is still a valid choice).

As the variety of motor controller implementations grows, I see this as necessary design to cover two scenarios

• [1] Student programmer wants to use an MC, say a TalonFX. What can a talon FX do? Instead of reading anything, they will just intellisense TalonFX(whatever)dot and peek at the values available.
• [2] Senior developer wants to write a wrapper to cover several possible MCs. They understand the hardware details of what each product can do and leverage the more general enums, knowing that there is no integrated-sensor for TalonSRX (for example).

Makes sense?