Why are there two classes (com.ctre.phoenix.motorcontrol.can.VictorSPX and com.ctre.phoenix.motorcontrol.can.WPI_VictorSPX)? It seems that if the WPI_ version does all the things that the CTR version does and more, such as simulation and WPILib drive class support. Are there things that the plain VictorSPX class can do that WPI_VictorSPX can’t? Why aren’t they just one class?
The WPI_ prefix versions implement WPILib-specific interfaces like MotorController and Sendable
But is there a reason those interfaces aren’t just implemented in the standard versions of the class?
Maybe because CTRE didn’t want their vendor library to depend on WPILib?
2 Likes
@viggy96 is correct. CTRE built their products and software library to be generic so it can be used by anyone from hobbyists to competitive teams, not just FIRST. By adding those interfaces to the base classes, they would be vendor-locking to the WPILib platform, which hobbyists, battlebots, etc almost certainly don’t need or want to use.
1 Like
Oh, that makes sense. Thanks!
I’ve wanted to deprecate MotorController for a while now, because the robot drive classes no longer need it, and it just adds another place for ABI breaks to occur; ABI breaks are an issue in FRC when vendors realistically only do one major release per year.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.