Re: [eclipse-incubator-e4-dev] Extension registry evolution - cross-post

[Michael Scharf <Michael.Scharf@xxxxxxxxxxxxx>]

Hi,

sorry for replying a bit late to this thread.....

Some time ago (in April) I described what I call MagicInterfaces:

http://dev.eclipse.org/mhonarc/lists/eclipse-incubator-e4-dev/msg00283.html
http://dev.eclipse.org/mhonarc/lists/eclipse-incubator-e4-dev/msg00285.html

The basic idea is very similar to the reima service injection: Magic interfaces
create adapters (using java.lang.reflect.Proxy) from interfaces to a given
implementation of a kind of DOM like "datastores" (like IConfigurationElements,
IDialogSettings, IMemento, ILaunchConfiguration, IPreferenceStore, ... or even
EMF).

It changes the focus: you define the interface and a factory generates at
runtime implementations of the interfaces and adapts the interface to the
underlying data structure. Instead of writing schemas you write interfaces.
It should be possible to generate the schema from the interface. The advantage
is that you don't have to worry about the underlying implementation. It is
hidden. And you act in the world of java. Refactoring etc. works.

Once the old DOM like interface are only needed for backward compatibility,
one can probably invert the adaption and generate (or probably hand write)
the old generic interfaces EMF (or whatever is used as the underlying
implementation).

What I really want to see is
- I want ONE way to access all the different generic DOM like data structures
- I don't want to generate code all the time. I want to use it "ad hoc"
  by going to a factory that creates the interfaces at runtime
- I want to generate code if I feel like (e.g. when performance matters)
- I want to access the data using interface when I feel like
- I want to access the same data reflective when it is appropriate
- I want to be able to subclass existing interfaces

EMF provides some of this and something like the reima injection
service or MagicInterfaces provide the missing pieces.

Is this Bloat? Maybe in the beginning. As the old interfaces retire
the bloat might go away. It is no bloat when it comes to the user.
All you do is define some interfaces and some magic service binds
it to the implementation..... Minimal dependencies to any implementation.
The small gate is the factory that injects the implementation.

Michael

> Hi,
>
> I think having IConfigurationElements mapped to actual Java objects is a 
> very good idea. The Riena project is using that now for roughly 4 month 
> with an implementation in its codebase that allows to
>
> - create Java objects from Extensions
> - define Interfaces for the ExtensionPoint schema
> - inject the Java Objects into any object that is interested in its 
> information (making the using code independant of extensions but simply 
> dependant on the interface object)
> - automatically re-injects the Objects if extensions are added or 
> removed (by installing uninstalling bundles)
> - create java instances for those attributes where the type is java
>
> Riena has defined an API that uses Extensions and OSGi Services in a 
> very similar way. You can inject Services or Extensions using one API. 
> We have a short not yet complete description in the 
> wiki http://wiki.eclipse.org/Riena_Getting_Started_with_injecting_services_and_extensions 
> and of course the code is in the latest M4 build of Riena 
> (http://wiki.eclipse.org/Riena_Getting_started) and we have quite a 
> number of Testcases to show how injecting Extensions and Services works 
> using the API.
>
> cheers
>
> christian campo
>
> Am 24.09.2008 um 21:20 schrieb Oleg Besedin:
>
> > [Cross-posted from the equinox-dev@xxxxxxxxxxx 
> > <mailto:equinox-dev@xxxxxxxxxxx>]
> >
> > What would you like to see in the extension registry 2010?
> >
> > If you have an opinion on how the extension registry can be improved, 
> > please visit:
> >
> >         http://wiki.eclipse.org/Equinox_Extension_Registry_Work
> >
> >         https://bugs.eclipse.org/bugs/show_bug.cgi?id=248340
> >
> > and leave your comments!
> >
> > So far we have identified several potential areas:
> >
> > - Create typed Java objects instead of forcing you to crawl through 
> > IConfigurationElements  (see 
> > http://wiki.eclipse.org/Equinox_Extension_Registry_Work_Objects for 
> > details)
> > - Expand ability to programmatically modify extension registry
> > - Add support for non-singleton bundles
> >
> > Does this sound like something you'd like to see in Eclipse?
> >
> > (Please use this mailing list for general discussions and bug / wiki 
> > for more detailed comments.)
> >
> > Thanks,
> > Oleg
> > _______________________________________________
> > eclipse-incubator-e4-dev mailing list
> > eclipse-incubator-e4-dev@xxxxxxxxxxx 
> > <mailto:eclipse-incubator-e4-dev@xxxxxxxxxxx>
> > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev