Re: [e4-dev] Dynamic Eclipse 4 with Clojure language

[Laurent PETIT <laurent.petit@xxxxxxxxx>]

2013/11/21 Paul Webster <pwebster@xxxxxxxxxxxxxxxxxxx>
>
> On Thu, Nov 21, 2013 at 10:00 AM, Laurent PETIT <laurent.petit@xxxxxxxxx> wrote:
>>
>> Hello,
>>
>> I'm Laurent Petit, main developer of Counterclockwise, the open source Clojure Plugin for Eclipse.
>
>
> Hi Laurent,
>
> I love your work :-)


Well, thank you :-)

>
>  So I'm currently experimenting with an interactive Clojure Console to modify the Model on the fly.
>>
>> I've been successful in getting parts from the IEclipseContext, and from them creating parts via MBasicFactory, etc.
>
>
> What version of eclipse are you targetting?  If you are targetting Kepler and beyond, you can use org.eclipse.e4.ui.workbench.modeling.EModelService.createModelElement(Class<T>) to create model elements instead of tracking down each individual EMF Factory.  If you need to support Juno as well, though, then you are correct to use the factories.


That's an open question. I'm doing this prospective work for the
development of Counterclockwise itself.

I'm hesitating between letting Eclipse 3 users stuck with the current
stable version, and embrassing Eclipse 4 from now on ... or add
dependencies on Eclipse 4 bundles via a fragment, and have only some
new features that would be usable from Eclipse 4.

I will conduct a Counterclockwise User survey in the next weeks to
know what position to adopt.

>  My current problem is the apparent requirement for implementing Handlers to :
>>
>> - have the classes pre-compiled (as opposed to being dynamically created via in-memory bytecode generation as Clojure does). I'm thinking this because of the required "class URI".
>
>
> AFAICT for handlers we use the class URI if the contribution object has not yet been instantiated.  If you create an instance from your class and call MHandler.setObject(theInstance) then set the URI to a string that provides a default failover NO-OP class just in case.
>
>
> There's also the runtime EHandlerService system.  You can associate an handler instance object with a command using org.eclipse.e4.core.commands.EHandlerService.activateHandler(String, Object) and bypassing the model completely.  This might be the way to go since if you add MHandler objects to the model, they'll be persisted (and how do you re-create the dynamic classes on the next startup?  Not impossible, but you'd probably have to do extra work to save other information in the model).


That's true.
With Eclipse 3 model, I had created a generic
IExecutableExtension/IExecutableExtensionFactory implementation, which
could then delegate to Clojure factory handlers like this:

       <class

             class="ccw.util.GenericExecutableExtension">

          <parameter

                name="factory"

                value="ccw.editors.clojure.nrepl-hyperlink-detector/factory">

          </parameter>

       </class>

Maybe I can simulate this with Eclipse 4 if I create a generic class
and I'm able to inject the E4 Model Element to it so that it can get
the clojure factory from its persistedState map ?
But I fear not: I haven't seen the equivalent of an
IExecutableExtensionFactory in E4. That would be the missing piece.

>>
>> - use @Execute annotation instead of implementing an interface.

>If you're generating the bytes for your classes on the fly, can you simply insert the runtime bytes >for @Execute and @CanExecute in front of those methods (I'm not that familiar with byte code >generation)?

I have found that I can declare annotation on Clojure types / records,
so maybe there's hope.