Re: [equinox-dev] Extension registry evolution

["Boris Bokowski" <bokowski@xxxxxxxxx>]

On Wed, Sep 24, 2008 at 3:19 PM, Oleg Besedin <obesedin@xxxxxxxxxx> wrote:
>
> What would you like to see in the extension registry 2010?

I just looked at
http://wiki.eclipse.org/Equinox_Extension_Registry_Work_Objects. I
like that you plan to use constructor and setter injection, this has a
lot of potential for simplifying things, but I would like to see a
more flexible approach.

Here are my comments:

(1) I don't like that clients cannot provide more than just one single
"context" object. For example, when contributing to the UI, there are
a whole lot of services that views or editors need from their context.
The Workbench provides these services, but with the API you propose
there is no way to have these directly injected into the provided
object, as in (for example):

public class SomeContributedView {
 public SomeContributedView(ISelectionService ss, IProgressService ps,
IWorkbenchHelpSystem hs) {
...
}

(2) IRegistryObject is odd - can you not split this into two
interfaces that we would recommend are being used whenever objects
need to be initialized, or disposed? How about:

package org.eclipse.equinox.common;

public interface IDisposable {
  public void dispose();
}

public interface IInitializee { // someone please propose a better name
  public void init();
}

Note that I already see three interfaces "IDisposable" in my workspace
(one in ECF, one in EMF, and one in Platform UI), and I suspect they
all could extend this common one.

Another possibility, since you are using reflection anyway, is to not
require clients to implement interfaces like this but rather call
their init() and dispose() methods should they exist.

(3) What about existing dependency injection frameworks? How does your
proposal relate to them? Some dependency injection frameworks use Java
annotations to specify defaults (Guice being one example). Wouldn't it
be good if clients could specify which dependency injection mechanism
they would like to be used? I am thinking of something in the
plugin.xml by which they could specify how the dependency injection
should be done.

(4) What about other languages, for example JPython, JRuby,
Javascript, Groovy etc. - all of these can run on the JVM.  Actually,
enabling (3) would help with this - if clients can specify a
dependency injection mechanism, that mechanism could be one targeted
at creating objects implemented in those other languages.

Boris