Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ease-dev] EASE could support "require" for loading core modules 

On 21.11.2014 19:01, Paul D. Fernhout wrote:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=452689
This reply is related to a discussion on the bugtracker. Paul raised some interesting questions which I like to share on this list as the bug might remain unnoticed. For interested parties to get the full context, please read the according bug.
First I'd like to explain a little more, why EASE has a loadModule() command, what it does and how to potentially get rid of it. 

-------------------------------------------------------------------------
Rhino, as we have implemented it in EASE allows to access all classes from the Java Class Library, along with all classes that are exported by loaded bundles of your running IDE. Thus people could write java-like code to be executed by Rhino. The problem is, people willing to write java-like code (with all the learning of APIs it requires) will write java code at the end. They will write a plugin, pack it into a feature and ship it with their product. They will typically not write scripts, maybe except for rapid prototyping. The EASE modules encapsulate "complicated" stuff into simple functions. The userbase it was initially created for typically has no understanding of object oriented design, classes, instances or even inheritance. Simple functions for simple tasks. No need to know about full qualified names and awkward script code, it would result in.
Still we did not want to provide a static DOM for our script languages, like lots of other scripting approaches for eclipse do. For one you could not extend it without touching basic EASE plugins. Second it would pollute your namespace with lots of classes preloaded in your engine. And finally: how would you define a useful set of common functions? Some do care about UI, others need scripting for git tasks, modeling, report creation, C++ compilation, name it. I guess you could never find a common base that satisfies everyone.
That's where modules come in place. Helper classes that encapsulate most common tasks. The idea is to bring EASE to the release train some day. Then other projects could start to build on it and provide their own modules. Personally I do not want to write modules for every task users can think of. I want the git guys to provide a git module, sirius people to add modeling modules and so on. They work on their code base all the time, they should be the best choice for such modules.
Admittedly to use modules you would have to learn yet another library mechanism and API. Yet to my knowledge nodeJS, requireJS and all the others will not help you anyway when you want to interact with eclipse - and that's what EASE is meant for in the end. Without interaction there is little use for loadModule() as there are better ways to work with libraries. 

-------------------------------------------------------------------------

So lets see what loadModule() does looking at a simple example:
Pretend we have a java class:
class Calc {
    @WrapToScript
    public int sum(int a, int b) { return a+b; }
}
On loadModule() we first create an instance of Calc which we inject into the script engine using a dedicated variable name: __MOD_class_whatever. 
Now we generate script code

function sum(a, b) {
    // preExecution
    __result = __MOD_class_whatever.sum(a, b);
    // postExecution
    return __result;
}
Nothing special so far. Now other modules might add hooks into the generation of the function above. They may add arbitrary code on preExecution and postExecution. 
Some ideas what we currently do with it:
* We also build UIs, which use script code below to accomplish some tasks. We add a module, that simply logs every call to a dedicated logger like this 

    some.singleton.Logger.log("sum(3, 5);");
What you get is a way to monitor what you do to the user. Users also learn the according script commands bound to a toolbar button or other UI element. This allows to learn the EASE API by simply playing with an UI. 

* We've built a test framework that adds postHooks
if ((__result instanceOf some.special.Assertion) && (__result.isError()) 
        // create some markers in the workspace, trigger alarms, ...

-------------------------------------------------------------------------

How do we introduce loadModule() to the engine:
Script engines accept extensions points for bootstrapping, things to do when a new engine is created. One of these extensions loads the basic Environment module by injecting something like this: 

    new o.e.ease.EnvironmentModule().loadModule("Environment");
This is an optional extension to the basic script framework and we could think of ways to disable it, so you could get a "raw" engine without any additions. If needed, raise a feature request for that. 

-------------------------------------------------------------------------
Finally I would like to address your example from https://bugs.eclipse.org/bugs/show_bug.cgi?id=452689#c4
Using the plain java code would not work, as you would have to run it in the UI thread - which you would not have access to. With Java 8 you could inject a function, to Display.syncExec() which would be wrapped to the required Runnable, but THAT code would look really complicated, yet doable. Still I prefer 

loadModule("UI")
setClipboard("Hello, World and: " + getClipboard());
We see that helping users to learn about EASE, its functionality and API is crucial. For now we have the Modules Explorer View - an invaluable little helper, there is help available for all the modules in "Help/Scripting/Loadable modules" and we started (along with you, Paul) to provide first script samples in the script repository. I also started to blog about EASE (http://codeandme.blogspot.com) a little more. Code completion (editor and shell) was added as a proof of concept, but is really rough so far.
The balancing act for us is to provide a simple environment for beginners, while still providing full access to almost everything for power users. Developers should be able to extend the framework without the need to touch core EASE bundles. And finally it should support that very special script language you never heard of but your users love. 

Love to hear your ideas on this

--
Christian

Back to the top