The eclipse editor in work

Bruno Medeiros brunodomedeiros+spam at
Thu Sep 18 07:23:11 PDT 2008

Ary Borenszweig wrote:
> Bruno Medeiros a écrit :
>> Frank Benoit wrote:
>>> Ary Borenszweig Wrote:
>>>> How can one implement plugins in D?
>>> In theory this can be made with a DDL like mechanism.
>>> IMO in the first run, it can be ignored and you just compile the 
>>> configuration you want.
>>> A dummy OSGi/Equinox API could be used, so the code is still compatible.
>> Yeah, I was thinking the same. A dummy OSGi which only supported 
>> static configurations (ie, no runtime loading/unloading) would 
>> probably be the best way, both because a full functional OSGi 
>> framework would not be the most important functionality of the Eclipse 
>> platform to have first, and because it doesn't seem DDL is mature 
>> enough for this task.
> The problem with that approach is that there are a lot of things in 
> Eclipse that you might or might not use depending on what you do or not 
> in a session. Eclipse loads *a lot* of things lazily, and tries to 
> populate the UI using as much stuff from the plugin.xml files as 
> possible. If you don't make that lazy, then Declipse will probably be as 
> slow as Eclipse, or worse.

Yeah, but in the beginning D-Eclipse would only have a few available 
plug-ins...: the core/Platform, a D IDE, and maybe a source control 
plug-in. I certainly don't see any prospects of porting JDT, CDT, Mylyn, 
WTP, GMF, EMF, etc.,etc. to it :P
Also, with a little more developed semi-mock OSGi, the initialization 
could be performed lazily. Only the dynamic loading (ie, loading code) 
would have to performed statically to avoid having to use DDL.

Bruno Medeiros - Software Developer, MSc. in CS/E graduate

More information about the Digitalmars-d-dwt mailing list