Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Dynamic Eclipse 4 with Clojure language

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.

>>
>>> 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";
        }
    }
}


Tom


Back to the top