Open tomtzook opened 7 months ago
So some good reason to switch:
Some reasons to stay:
I should add, that this switch would not necessarily mean we abandon the idea of using our own library for improving over the years. We can still do that, and will. However, the base of our code will be with WPI.
I would also probably never fully abandon FlashLib, as I sometimes find it useful as a platform for other things. But these would not be used in our team.
@yaronkle @Maayan-Luzon @NoamZW
We would need to discuss this after the competitions.
I mentioned these two points in favor of switching:
Switching will allow easier work with other Teams and their code.
Most third-party FRC framework (like pathplanner) are already integrated with WPILib. For our use, we must make some extra work to integrate.
However, these points may be mitigated without switching by running Commands
over our scheduler using a kind of wrapper, which will be some special Action
. Its really not that complicated for most situations. For groups, this will be kind of a problem.
Obviously, we can always make integration for which framework manually. Though changes to that framework will require us to make some extra work. So the first option seems more realistic.
Recently I was required to debug a problem with a Command
, as part with my work with another team. I found the CommandScheduler
(WPILib's Scheduler) lacking in terms of information provided as to the execution of Commands
. Other than the ability to attach a few callbacks and limited information available as a Sendable
, there wasn't much else.
In contrast, FlashLib's Scheduler extensively uses logging and provides much information through OBSR (NT for FRC). Which makes it easier to know what's going on. With the addition of features from #111 , users have a lot of power in their hands to understand the execution state.
Honestly, I'm just really biased. We should make the switch.
LOL, Is it possible to create plugins for specific functionalities instead of everything?
On Mon, Mar 18, 2024, 12:31 PM Tom Tzook @.***> wrote:
Honestly, I'm just really biased. We should make the switch.
— Reply to this email directly, view it on GitHub https://github.com/Flash3388/FlashLib/issues/113#issuecomment-2003519539, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCQSZDCATQDVY5KINYGAJDYY267PAVCNFSM6AAAAABEAN3NTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBTGUYTSNJTHE . You are receiving this because you were mentioned.Message ID: @.***>
LOL, Is it possible to create plugins for specific functionalities instead of everything?
Not so much plugins as extensions built upon WPILib. But yeah, it possible, with limitations of course, as the code isn't meant to be extendible in various locations. It is what I'm planning to do though, given a full switch.
Which parts of FlashLib do want keep?
We are making the switch.
Originally, when first developed, FlashLib was made to provide components which did not necessarily exist, or had some problems, in WPILib or otherwise.
But over the years, we started switching to different, better, and sometimes new frameworks or produces. For example:
Now the one components which is fully used is the scheduler.
So the question must be asked: should we stop using it in favor of replacements?
I will be using this issue to discuss (sometimes with myself) whether to stop using flashlib or not.