polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject javax.script
Date Sat, 08 Apr 2017 04:36:05 GMT
Hi,
I mentioned yesterday that I am working on putting javax.script as the
integration point with JavaScript and Groovy instead of our direct
dependencies on each.

There is one thing that 'bothers me'; Scopes.

So a single class ScriptMixin will handle the reading and invoking the
javax.script side, but what is the scope?

ScriptMixin is the supplied Mixin to any number of Composite Types for any
number of interfaces and methods.

I *could* create one ScriptEngine per method, or per method.declaringClass,
or per Composite primary type or per Polygene runtime.

A ScriptEngine has ScriptContexts which in turn holds the Bindings. The
Bindings contain the integration objects (accessible in both Java and
script language) as well as the script itself. ScriptContext holds 2
Bindings (GLOBAL and ENGINE), and the handling of them internally is
non-intuituve.

Now, the question is what is the scope of the script itself? Should it be a
global script per primary type, or should we isolate each composite
instance with its own script engine? Or should it be a global script
environment to really open the gates of problems?

I tend to lean on "script engine per composite instance", but it feels a
bit heavy-handed. I guess it doesn't matter which one if the use is
Services, but for short-lived composites it would also mean one compile
cycle per creation (==slow?)

Ideas and feedback most welcome.


For those who have no idea what I am talking about;

It has been possible to implement the mixin methods of composites in other
languages, such as JavaScript and Groovy.

package com.abc.script;

@Mixins( ScriptMixin.class )
public interface SomeType extends ScriptReloadable
{
    String doMyBidding( String whatever );
}

and then have (for instance) JavaScript in a resource
com/abc/script/SomeType.js with;

function doMyBidding( whatever ) {
    return "Great: " + whatever;
}

and the ScriptReloadable.reloadScript() will recompile it for next time,
i.e code replacement in runtime.

Inside the script environment, things like serviceFinder,
valueBuilderFactory and so on are available as global variables.

Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message