Hi @arkhipenko,
your repo does not have 'discussions' feature enabled, so let me create an issue instead.
I was thinking about some features for TS that would be nice to have around, call it todo or not-todo list :)
Share ideas and consider if it worth the efforts to invest time into contributions or feature requests.
so, just some of the ideas that came to my mind:
xx - so much defines in code
there is so much features available in the lib and all controlled by a bunch of processor macro's. Some of them contradicts the others, some are there just to save resources, some really change lib's behavior. It becomes tricky to tailor it for various purposes, or sometimes even not possible to choose between the two.
One possible (but not easy) way to make it more configurable and extensible could be to use more Object-Oriented design (we already have objects anyway). So design a dumb Task object prototype and create a bunch of inheritable objects from it. Instead of include macro's we can simply choose between different inherited Task objects with it's own features. i.e. it could eliminate options like LTS_POINTER, OO_CALLBACKS, TIMEOUT, SCHEDULING_OPTIONS, maybe some others. Should not be an issue for the lib size, we rely on linker's here to chop off unused parts.
The same approach could be used with Scheduler to implement PRIORITY, TIME_CRITICAL or so.
Sure there could be a lot of caveats, incompatibility, etc... but it's a way to make lot's of things easier and to adopt and extend features easily either in the lib or in user code.
xx - RTOS specifics
lib sticks to Arduino's API, but as more platforms gaining rtos core it could be really handy to use some rtos features to own benefit. What comes to my mind - native mutexes, thread-safety locks, running separate threads from loop, priority, etc.
xx - need a CI tasks
with all the flags around need an automation to cover examples builds at least. Having examples in Arduino's format is not that good here, but doable. Platformio is more flexible here.
xx - Arduino IDE legacy in a nightmare
a decade(s) have passed and Arduino IDE is still the same lacking one of the most requested feature - build time define macro's to configure LIB's features. All-in-one .h file is an ugly workaround that complicates everything. Have no idea what to do with that, but it is an anchor chain on your neck :)
arkhipenko
commented
1 year ago
Hi @arkhipenko, your repo does not have 'discussions' feature enabled, so let me create an issue instead.
I was thinking about some features for TS that would be nice to have around, call it todo or not-todo list :) Share ideas and consider if it worth the efforts to invest time into contributions or feature requests. so, just some of the ideas that came to my mind:
xx - so much defines in code there is so much features available in the lib and all controlled by a bunch of processor macro's. Some of them contradicts the others, some are there just to save resources, some really change lib's behavior. It becomes tricky to tailor it for various purposes, or sometimes even not possible to choose between the two. One possible (but not easy) way to make it more configurable and extensible could be to use more Object-Oriented design (we already have objects anyway). So design a dumb Task object prototype and create a bunch of inheritable objects from it. Instead of include macro's we can simply choose between different inherited Task objects with it's own features. i.e. it could eliminate options like
LTS_POINTER,OO_CALLBACKS,TIMEOUT,SCHEDULING_OPTIONS, maybe some others. Should not be an issue for the lib size, we rely on linker's here to chop off unused parts. The same approach could be used withSchedulerto implementPRIORITY,TIME_CRITICALor so. Sure there could be a lot of caveats, incompatibility, etc... but it's a way to make lot's of things easier and to adopt and extend features easily either in the lib or in user code.xx - RTOS specifics lib sticks to Arduino's API, but as more platforms gaining rtos core it could be really handy to use some rtos features to own benefit. What comes to my mind - native mutexes, thread-safety locks, running separate threads from loop, priority, etc.
xx - need a CI tasks with all the flags around need an automation to cover examples builds at least. Having examples in
Arduino's format is not that good here, but doable. Platformio is more flexible here.xx - Arduino IDE legacy in a nightmare a decade(s) have passed and Arduino IDE is still the same lacking one of the most requested feature - build time define macro's to configure LIB's features. All-in-one .h file is an ugly workaround that complicates everything. Have no idea what to do with that, but it is an anchor chain on your neck :)