|
Re: Feedback Thread: WPILib
I liked the functionality that WPILib provides, but I don't think it does a very good job of utilizing OOP principles. As an example: many classes inherit from SensorBase, and SensorBase then has specific methods for each of its child classes. That's not really how inheritance is supposed to work.
A good example of OOP in WPILib is the PIDSource interface. Unfortunately, this seems to have been added on as a side feature, and doesn't really integrate well with the rest of the library. It is, in my opinion, too specific; for something to be PID-compatible, someone has to have written a pidGet() or pidSet() for it. More often than not, pidGet() simply calls get(), and it would have been nicer to extract the getters and setters themselves into interfaces. In my team's code, we have four interfaces: AnalogIn, AnalogOut, DigitalIn, and DigitalOut. These have get(), set(), isOn(), and setOn() methods, respectively. Our PID class, therefore, automatically works with any input or output of the correct form, without us having to write special pidGet() or pidSet() methods in each class we want to be PID-compatible. I would like to have seen WPILib utilize these time-saving OOP features more often.
One of my favorite features of WPILib is the FPGA interfaces. I wish WPI would expand these and make them more configurable. For example, the gyro accumulators are great, but there are only two of them, and you can't choose which two analog inputs to attach those to. Moreover, the accumulators don't give us much control in the way of input filtering (thankfully there is a deadband function).
Finally, thank you so much for the new vision library! You really got it right this time; we downloaded the sample code to our robot and had accurate tracking of the target on the first try. Awesome!
__________________
Go directly to queue. Do not pass pit.
|