[news.eclipse.technology.equinox] Re: Plugins - singletons or not?

[Mel Martinez <melm@xxxxxxxxxx>]

Jeff McAffer wrote:
> "pkriens" <Peter.Kriens@xxxxxxxx> wrote in message
> news:3E8800D9.4050203@xxxxxxxxxxx
>
> > I am a bit confused. If we have dynamic plugins, we have the problem
> > that they can go away. The patterns described to handle plugin creation
> > are therefore not applicable anymore, isnt it?
> >
> > If plugins come and go, we need a service registry approach where the
> > plugins are registered and unregistered. Access to static fields and
> > getInstance()/getDefault() methods seem to be not sufficient?
>
>
> Right.  In actual fact, the plugin registry already provides this function.
> If plugin A is deactivated and reactivated you can safely reference the new
> one via the registry.  Same for uninstall, install, update, ...
>
> For my money getDefault/getInstance should be
>     return Platform.getPlugin("my id");

I couldn't agree more with that last statement except that it doesn't go 
far enough to address Peter's concern.  To remove need for access to the 
class one shouldn't even be using a static getInstance() method. 
Instead, they should always be going directly to the 
Platform.getPlugin("my id") modus, and probably Plugin implementation's 
should not even be providing a getDefault()/getInstance() accessor.

Since this is not a strongly enforced convention, we may have problems 
going forward with unnecessary coupling arising from this.  I guess this 
dependency is flagged broadly under the <requires> element.

Mel