Hey @quentin , thanks for these insightful and very valid comments.
Nonetheless I’d like to justify this choice a little bit:
I actually agree with you on the OO interface, and the refactoring of the sensor classes I did this summer actually provides this, you subclass Sensor and implement the getSensorAngle() method, and done! Maybe I should have called it read(), but in essence its the same.
The drivers I’ve written in the drivers repo all follow this pattern. I generally use PlatformIO and I’m writing C/C++.
But for a beginner user, or someone coming from the mech eng world with little connection to programming, they see a different view of the world. They use ArduinoIDE, and are working in an .ino file. ArduinoIDE makes it very easy for them to pull in a library, but not to work with multiple .cpp and .h files, it doesn’t really have that philosophy.
So for such a user, it is actually much easier to write a callback that connects a library, all in the same .ino file as main() and setup(), than it is to create a new class. The required knowledge on the syntax of C++ is also much less.
That’s because the Sensor class does have its internal fields to initialise, and so in this construct you have to call both Sensor.init() and provide the initSensor() method. A bit confusing due to the naming maybe.
Lets see how this goes. Since the refactoring of the Sensor API a few people have asked questions about new sensors, and I’ve even seen one attempt with the OO approach. Lets see if this approach leads to more people being able to use new sensors independently (and hence less hardware specific code to maintain in the library).