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


Bob Jacobsen
 

I don’t know of anything that would break.

Formally, it might be good to go through a deprecation cycle. But the problem is that, if we want to end up with the AbstractProxyManager and AbstractProvidingProxyManager names, in the meantime your code is a bit of a mess (because the problem is that ProvidingManager is implemented too high)

To do this:

- Create the classes as described earlier.

- In AbstractProxyManager, leave the ProvidingManager method in place and marked as deprecated; have it show a runtime deprecated warning (Log4JUtil.deprecationWarning)
- Have your implementation throw UnsupportedOperationException for provide(..); mark it as @Override

Eventually, the ProvidingManager provide can be removed from AbstractProxyManager, which will remind you to remove it from your classes via the @Override

But I don’t think it’s really necessary.

Bob

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

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?
--
Bob Jacobsen
@BobJacobsen

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