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


Bob Jacobsen
 

By far the most useful approach is to have system name completely describe how to access the hardware device. A system name where the suffix can be parsed out to give enough information to create the object is just easier to manage from e.g. scripts and file loading. Examples are C/MRI Light/Turnout/Switch (LTS) which have the node and pin encoded in the address; the Power Line connection which specifies house code and device code, and Grapevine which encodes all sorts of things in its names.

https://www.jmri.org/help/en/html/hardware/cmri/CMRI.shtml
https://www.jmri.org/help/en/html/hardware/powerline/Names.shtml
https://www.jmri.org/help/en/html/hardware/grapevine/Names.shtml

That’s not the complete configuration, of course. Things like feedback sensors still need to be directly configured. But it’s enough to _create_ the object so that it can be retained, even if that configuration will be happening later.

But in the alternative that for some reason this can’t be done, you can always reimplement a different ProxyServer that doesn’t also implement ProvidingManager. A clean way to do this would be to create a new AbstractProvidingProxyManager that is a subclass of AbstractProxyManager, move all the existing subclasses to that, and then have AbstractProxyManager provide everything _except_ the ProvidingManager implementation. That way we end up with AbstractProxyManager being a minimal implementation of ProxyManager hence Manager, and the AbstractProvidingProxyManager still providing the super classes for everything that’s there now.

Bob

On Jan 5, 2020, at 5:56 AM, danielb987 <db123@...> wrote:

I'm implementing managers for AnalogIO and StringIO. I'm going to add a generic ProxyManager and a specific LocoNet manager for these.

AbstractProxyManager implements ProvidingManager, so I must add the method provide() in the ProxyManager. But I cannot create an AnalogIO or a StringIO from only a system name, so this method should always fail, at least for the LocoNet manager. What is the proper way to handle this? Throw an IllegalArgumentException("not supported") or throw an UnsupportedOperationException("not supported") ?

Daniel
--
Bob Jacobsen
@BobJacobsen

Join jmri@jmri-developers.groups.io to automatically receive all group messages.