Unfortunately, the ArduinoIoTCloud library declares its ownColor class. This makes it impossible to use Modulino.h in an IoT Cloud project. Likely, other third-party libraries may declare a Color class considering it's a pretty generic name, as well as variables or constants named RED, BLUE, GREEN...
We need to find a future-proof solution to avoid collisions.
Proposal 1 (easy)
Let's not expose any class for colors nor constants in Modulino. To set LED color we'll use this basic signature:
Let's create an official Arduino_Color library exporting an Arduino_Color class providing a very generic and versatile API that any third-party library can implement. This library would also export a Color alias in the global namespace, except when a user tells it to not do so:
Unfortunately, the ArduinoIoTCloud library declares its own
Color
class. This makes it impossible to use Modulino.h in an IoT Cloud project. Likely, other third-party libraries may declare aColor
class considering it's a pretty generic name, as well as variables or constants namedRED
,BLUE
,GREEN
...We need to find a future-proof solution to avoid collisions.
Proposal 1 (easy)
Let's not expose any class for colors nor constants in Modulino. To set LED color we'll use this basic signature:
Proposal 2 (more ambitious)
Let's create an official
Arduino_Color
library exporting anArduino_Color
class providing a very generic and versatile API that any third-party library can implement. This library would also export aColor
alias in the global namespace, except when a user tells it to not do so:Then, we modify the ArduinoIoTCloud library to use this one as a dependency. Ta-dah, we'd get magic interoperability between cloud and Modulinos: