You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is mainly to get my thoughts out about the core.matrix style implementation selection and to centralize the discussion of it.
I don't think the effort of building a pluggable back end is worth it for the fairly constrained number of possible gpio implemenations (sysfs for linux, maybe a jna one, something for windows? other?)
Unlike a matrix library in which you would need to know about the impl in many places, applications using gpio code are likely to allocate all of the pins up front. It does not seem likely that you would have dozens of files all needing to know about how to allocate pins in the same exact way
This is why I believe there should be a separation between the GPIOPin protocol and the reserve/release protocol. In my mind, only one point in the code would care about how to allocate pins, everything else simply acts on a pin it has been given.
Due to the previous two points, should someone really need to propagate the ability to allocate pins throughout their code base, I would use something like https://github.com/stuartsierra/component to manage it.
The text was updated successfully, but these errors were encountered:
Should the pluggable impl be pursued, we could use https://github.com/ztellman/potemkin so that the code can be logically separated, but still have all of the impls behave as if they were defined in the gpio namespace
This is mainly to get my thoughts out about the core.matrix style implementation selection and to centralize the discussion of it.
The text was updated successfully, but these errors were encountered: