Re: What should ProvidingManager.provide() return if not supported?


2020-01-05 16:29 skrev Randall Wood via Groups.Io:
Also, by your design, it seems I could have two different NamedBeans
that attempt to write (and I assume read) two different types of data
(say 8 bit integer vs float or 16 bit integer vs variable length
string) from the same device/SV. That suggests you should have a
NamedBean for an IO device, not for an IO device by type of data
Both AnalogIO and StringIO are NamedBeans. So they should have different type letters.

For me, the important part is to implement managers for AnalogIO and StringIO. I choose LocoNet, since that's what I'm used to and have to work with. But it could be JSON, C/MRI or anything else instead. I just want some reference implementation to let people use AnalogIO and StringIO in real life.

It seems that the easiest way forward is to let AnalogIO_Manager and StringIO_Manager implement ProxyManager and not extend AbstractProxyManager. And I think the best way to do that is to add a AbstractNonProvidingProxyManager that is parent to AbstractProxyManager.

abstract public class AbstractNonProvidingProxyManager<E extends NamedBean> implements ProxyManager<E>, Manager.ManagerDataListener<E>

abstract public class AbstractProxyManager<E extends NamedBean> extends AbstractNonProvidingProxyManager<E> implements ProvidingManager<E>

AbstractNonProvidingProxyManager is a proxy manager that doesn't provide named beans.

AbstractProxyManager is a proxy manager that provides named beans.


Join to automatically receive all group messages.