Plugin name: Kaleidoscope-LayerHighlighter
Author: Brian Cully bjc@kublai.com
Source URL: https://github.com/bjc/Kaleidoscope-LayerHighlighter
Description:
Highlights a layer with an LED effect when it’s locked. Basically the same thing as the Kaleidoscope-NumPad plugin, but can have multiple instances for multiple layers, and none of the NumLock checking behavior.
This plugin is working well for me, but I’m looking for some feedback around the instantiation model. I haven’t seen other plugins do this, rather they seem to go for a singleton approach. I can’t see any reason why creating instances would be bad, but would love to know.
The goal here was to create something slightly more generic than the NumPad plugin so you could apply it to your own layers. If the code is fine as designed now, I’d personally like to see it moved to Kaleidoscope proper, with the NumPad plugin using it, just to save on progmem space.
I’m not the expert in this, but I believe it’s to do with the very limited environment of the Arduino – something like dynamic memory allocation being pretty undesirable in this context.
EDIT: link to discussion; apparently it’s not necessarily bad, especially if it’s just one object being allocated once, but mainly a style of embedded programming
You can have objects instantiated from the sketch, at compile-time - no memory allocation there. This is done for the SolidColor LED effects, for example. The Arduino-style is to have a singleton object, because that’s supposedly easier for the end user (no need to instantiate). But there’s nothing wrong with instantiating from the sketch either, if the circumstances prefer that over a singleton.
Good, that’s exactly what I’m doing here (there’s no new in sight, fret not). I figured it would be safe, and figured I would see other projects doing it, but I guess the singleton pattern is simpler, and most plugins don’t expect multiple instances.