polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <paulmer...@apache.org>
Subject Re: javax.script
Date Sat, 08 Apr 2017 12:58:42 GMT
Having a script scope per composite instance makes sense to me. Script
scopes allows scripts to hold state, we don't want to share state
between composite instances. Just like you said, this is not a
performance issue for Services. And if you need single use composites
then that's probably because you don't want to share their state.

Ideally we would be able to do the "compilation" once per composite type
and then "clone" the scope, or use "sub-contexts" for each instance.
Don't know if that's possible using the javax.scripting api though.

Niclas Hedhman a écrit :
> 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

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