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


danielb987
 

Bob

I sent my mail before I got yours.

Can I change AbstractProxyManager to not be a ProvidingManager without breaking anything? If so, I will be happy to do that. I was afraid that since AbstractProxyManager is public, I couldn't do that. But maybe it's no problem for classes in the jmri.managers package?

Daniel

2020-01-05 16:49 skrev 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.