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" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/26/2008 10:01 AM Please respond to Equinox development mailing list <[email protected]> To "Equinox development mailing list" <[email protected]> cc Subject Re: [equinox-dev] Extension registry evolution On Wed, Sep 24, 2008 at 3:19 PM, Oleg Besedin <[EMAIL PROTECTED]> 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 [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
