Re: What should ProvidingManager.provide() return if not supported?
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.
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.
On Jan 5, 2020, at 5:56 AM, danielb987 <db123@...> wrote:--