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

["Jeff McAffer" <jeff_mcaffer_REMOVE@xxxxxxxxxx>]

"Mel Martinez" <melm@xxxxxxxxxx> wrote in message
news:b6a99d$28t$1@xxxxxxxxxxxxxxxx
> Jeff McAffer wrote:
>
> > Yes.  I am a little unclear about the need to remove references to
classes.
> > While this may be a good thing in general, clearly plugins are going to
> > reference classes from other plugins.  Clearing up this one case does
not
> > solve the problem.  So what am I missing here?  Are you proposing that
all
> > cross plugin class references use some sort of service registry
mechanism?
> > As a point of interest, how does that work for subclassing,
implementing,
> > casting etc style relationships?
> >
>
> Plugin subclasses are a special case compared to other classes in the
> plugin packages because they provide 1)based on the lifecycle, the
> Plugin subclass provides a logical starting point of initialization for
> the rest of the plugin and 2) a platform-defined API for accessing a
> variety of plugin-specific services (for example access to
> Plugin.getPluginPreferences() provides a very plugin-specific service)
> without need for visibility of the particular plugin's classes.
>
> In other words, (1) provides reason for subclassing the Plugin class and
> 2) shows that cross-plugin utilization can happen without specific class
> visibility.

Agreed.  Relating this back to the original topic, we should advise against
using MyPlugin.getDefault() and recommend Platform.getPlugin("myPlugin").
Generalizing this, one of the tips and tricks for writing dynamic plugins
should include "avoid references to classes from other plugins where
alternatives exist or can be designed in".

Do you have a common usecase for one plugin to reference another's generic
plugin services (e.g., preference store) and have no references to any
classes from the plugin.

> Thus, a best practice for a component provider is (as Olivier has
> mentioned repeatedly) to put the public interfaces and abstractions in
> one 'B' plugin (which would tend to not get unloaded) and put
> implementations in separate 'C' plugin(s) that can be unloaded.
>
> And a best practice for a component consumer 'A' is to 1) only compile
> against the 'B' plugin's classes and 2) never retain stateful reference
> to objects pulled from other plugins.

right.  This is the service model.  It gives you finer granularity for
talking about changes.  We can think of each plugin as one big service that
can change in various ways.  See the registry delta discussion.  It is still
possible to have finer granularity as complementary function.

> > The <requires> elements tell you that if A requires B and B is shutdown,
> > replaced, ... A needs to do something.  The straightforward approach is
to
> > shutdown and restart all the dependents (or the whole platform) in these
> > situations.
>
> Yeah, I think that the straightforward solution is that if A requires B,
> and B exports any classes, the assumption must be that A requires class
> visibility and must be shutdown as well.  That supports the current
> model.  As an enhancement to the relationship, though, we could extend
> the plugin.xml so that when A specifies that it <requires> B, it
> optionally can specify that it listens for events which would allow it
> to clean up.  In that case we would try to unload B without shutting A
> down as well.

The registry deltas allow for this information to be transmitted but
currently there is no way to say that A should not be shut down.  Imagine
that as a result of being told of B's shutdown, A could respond with "shut
me down too" or "B?  what B?".  Default would be the former.  Smarter
plugins could do the latter.

Jeff