[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Dynamic Eclipse 4 with Clojure language
|
= Update Status
== Current development questions
I have focused on how to do model contributions these last days.
I have created a Model Processor, and written helper functions to
manipulate the model from Clojure scripts.
My final idea is to create a representation in Clojure of what needs
to be added to the model, and then create a (merge! application
contribution) that would add/update everything that is in the
contribution map, and remove everything that is not used anymore.
I will probably use tags to handle what needs to be deleted: after the
additions/updates to the model, every element of the model with tag
"counterclockwise" that has not been "seen" during the merge would be
mercilessly removed.
== Prospective questions
I'm trying to start thinking about user contributions to my plugin.
Some may want to use dependencies (jars) that are not declared in
counterclockwise's bundle.
If I follow this route, a "clean" solution would be to dynamically
create an OSGi bundle per user contribution, and then install/start
this bundle.
But .. the bundle would be started after the workbench has been
started. Would it be too late for the extension points for e.g. the
Model Processors to take place, etc. ?
2013/11/25 Laurent PETIT <laurent.petit@xxxxxxxxx>:
> 2013/11/25 Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>:
>> On 25.11.13 09:53, Laurent PETIT wrote:
>>> 2013/11/25 Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>:
>>>> On 23.11.13 00:32, Laurent PETIT wrote:
>>>>> Clojure & Eclipse 4 Update status:
>>>>>
>>>>> = TL;DR
>>>>> - "org.eclipse.e4.languages" extension point is *the way* to glue
>>>>> Clojure and the E4 Model together.
>>>>> - Having DI / Behavioral Annotations work from Clojure-only without
>>>>> any java class involved will require some more work from my part
>>>>> (generating bytecode via ASM).
>>>>>
>>>>> = Detail
>>>>>
>>>>> == Annotations
>>>>> E4 Annotations and Clojure Types don't work well together. Anyway,
>>>>> Clojure Types weren't really made for this usecase, so:
>>>>> - as a first step I just created stub java classes with annotations.
>>>>> - in a second step I intend to generate annotated classes dynamically
>>>>> via the ASM (bytecode generation / manipulation) library.
>>>>>
>>>>> == Contributions via contributionURI
>>>>> Tom made me look closely at how ReflectionContributionFactory works.
>>>>> And it includes a working hook to provide my own
>>>>> IContributionFactorySpi, via the "org.eclipse.languages" extension
>>>>> point, like this:
>>>>>
>>>>> <extension point="org.eclipse.e4.languages">
>>>>> <language
>>>>> contributionFactory="ccw.util.ClojureContributionFactorySpi"
>>>>> name="clojure">
>>>>> </language>
>>>>> </extension>
>>>>>
>>>>
>>>> As you can see the SPI allows to call methods as well. So I ask myself
>>>> if we could tunnel method calls through the SPI as well, hence no need
>>>> have annotations.
>>>>
>>>> Looking at the call method i'm not sure although if we don't need a
>>>> different signature.
>>>
>>> I have indeed not taken the second method of the SPI into account.
>>> Just throwing a NotSupported exception at the moment.
>>> A quick seach for callers returned nothing for this method as well.
>>>
>>> So I haven't thought about possible usages of this method call. For a
>>> language like Clojure which uses concepts of functions preferably to
>>> objects with methods, I'm not sure it will help a lot if the semantics
>>> are "calling a method of an object" (as opposed, for instance, as
>>> "leveraging some feature - such as @Execute-ing for some object")
>>> => So indeed, the answer for my usecase could depend on what exact
>>> information the signature of this method conveys.
>>>
>>
>> Well I think we should rethink the API maybe. I really don't want you to
>> implement some ASM stuff. What our invoke stuff is to call methods not
>> by name but by behavior.
>>
>> Maybe it is as simple as given to rename methodName with behaviour name
>> so that i matches the ContributionFactory#invoke better?
>>
>> I think we should not force anyone to implement java-bytecode! But like
>> i said there is noone who a really explored this multi-lang support
>> after the intial ideas have been implemented.
>
> Indeed, looking at the method signature, it seems that everything I
> need is there, and if indeed methodName really means behaviorName,
> then maybe what remains to be done (how hard would that be?) is to
> also use the IContributionFactorySpi implementation for calling
> behaviours on the object.
>
> In the mean time, I may still have to either live with the current
> state of affairs or play with ASM anyway, but I'm willing to use this
> method in the end, so if I can help ...
>
>>>>> This is perfect, it allows me to write contributionURIs like
>>>>> contributionURI="bundleclass://ccw.core/clojure/some.namespace/some-var"
>>>>>
>>>>> This will allow me to totally leverage the Eclipse 4 Model from
>>>>> Clojure, without compromises!
>>>>>
>>>>> Please, please, don't tell me you intend to deprecate / remove
>>>>> org.eclipse.e4.languages, it's a fantastic hook for alternate
>>>>> languages on the JVM !
>>>>
>>>> To my knowledge you are the only one using this and it's NOT official
>>>> API yet
>>>
>>> Not sure I'm the only one to use it: I have seen mentions of usages of
>>> the org.eclipse.e4.languages extension point here:
>>> http://wiki.eclipse.org/E4/JavaScript, as returned by Google with a
>>> search on ( "org.eclipse.e4.languages" javascript )
>>
>> The url more talks about the very general javascript support which
>> includes the complete bundle description, ...
>>
>> There have been our initial tests to get JavaScript going but there was
>> no progress since a long time on this.
>>
>> Our idea was to provide the meta information in JavaScript in a meta
>> block IIRC
>>
>> {
>> methods : [
>> {
>> name: "createUser",
>> behavior: "@Execute"
>> argumentKeys: [
>> "my.service.Userservice",
>> "key.username",
>> "key.password"
>> ]
>> }
>> ,
>> {
>> name: "canCreateUser",
>> behavior: "@CanExecute"
>> argumentKeys: [
>> "UserRole"
>> ]
>> }
>> ],
>> classDef: {
>> function createUser(userService,username,password) {
>> return userService.createUser(username, password);
>> }
>> function canCreateUser(role) {
>> return role == "admin";
>> }
>> }
>> }
>>
>>
>
> Got it.
>
>> Tom
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
