[Request For Comments] Should FL-LIB be imported in the project?

[flplv]

Currently react.o has its own implementation and tests for linked lists, FIFOs and arrays.
These same storages have been copied to a new project called fl-lib, my own C and C++ library with reusable storages in a single header file.

There are improvements that must be done to some storages, linked list should be reimplemented to match Linus Torvalds suggestions, in instance. Every time we change the storages I'll have to edit two projects. Besides, its 2017 and I really wonder if we have to re-re-re-re-re-invent the wheel every time.

So, here comes the dilemma: Should we remove react.o's implementation of storages and import the fl-lib to the project?

Pros:
fl-lib is a storage library: tests will have more coverage and it will be used by more projects.
It's gonna be easier to maintain.

Cons:
We will add more name into the client namespace that are not reacto_ prefixed, fl-lib has fl_ prefix.
It's not that elegant in the beauty of coding standpoint to add this lib.

At the end, this decision is more taste related than technical related, that's why I can't decide by myself. I'm having hard time to choose beauty over maintainability or the other way around.

What do YOU choose?

[jknGH]

Hello Felipe - this is really an attempt to get in touch about reacto. I am thinking of implementing/using a reactive framework in a small embedded system and came across this work of yours. I'd be interested in its current state and what you have done with it since inception ;-). Your LinkedIn account listed via github doesn't seem to exist... Cheers from the UK, Jon N

[flplv]

Hello Friend. AFAIK this project was used in a bluetooth product, and I used it on my sous vide machine. This project has a rough API because it uses plain C, it is fully type checked and has no heap, for modern standards I would recommend you to basically copy react.o ideas in your own C++ implementation, even without heap the templates in c++ will give you a better API than this project, which is exactly what a tram under my mentorship did for a comercial firmware on Robotics. You are quite correct in aiming for the reactive support in firmware, every firmware has a real time and a reactive portion, ISRs are great for the first and an event loop like react.o is great for the latter. Cheers from the UK too ;) My linkedin is https://www.linkedin.com/in/felipelavratti, it is outdated tho, I work in Cambridge now. Best!!!

On Fri, 23 Apr 2021 at 10:07 jknGH ***@***.***> wrote: Hello Felipe - this is really an attempt to get in touch about reacto. I am thinking of implementing/using a reactive framework in a small embedded system and came across this work of yours. I'd be interested in its current state and what you have done with it since inception ;-). Your LinkedIn account listed via github doesn't seem to exist... Cheers from the UK, Jon N — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFSEO6ICJEISHTOA4TSKY3TKE2D3ANCNFSM4DIIYMOQ> .

-- Enviado do Gmail para celular