Re: [equinox-dev] Extension registry evolution

[Mark Rogalski <rogalski@xxxxxxxxxx>]

Not to throw a fly in the ointment,
but some of the designs being discussed would not work on CDC/Foundation
1.1. With Eclipse based solutions being deployed on more and more mobile
devices, I think this should be an important consideration.  If we
introduce non-Foundation compatible, we'd probably have to split Eclipse
into Desktop and Mobile versions and apps would no longer be binary compatible
between them.  Of course it is always a difficult choice of sticking
with compatibility vs. taking advantage of new innovations.

"Boris Bokowski" <bokowski@xxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

09/26/2008 10:01 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	"Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] Extension registry evolution

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
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev