Mailing-List: contact dev-help@polygene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@polygene.apache.org
MIME-Version: 1.0
Reply-To: niclas@hedhman.org
In-Reply-To: <CADmm+Kf-MSuDGFnH7OVSZBrKR9z-Eta9_Y90-zDNnLSrkqYVcg@mail.gmail.com>
References: <CADmm+KcaXvDjJ0-z-CJ-fKjDN33fB2P9KQsk-qUm_dot9yA1WA@mail.gmail.com>
 <58E8DE82.10609@apache.org> <CADmm+Kd2AGCETqRTnb9sT84N7wr0DQy+M1xLooJycONJebS+3g@mail.gmail.com>
 <CADmm+KdCa6i0sBcoq2GKVYAKadzxqb=vgo=y6vQNxgrA_p3fDQ@mail.gmail.com>
 <CADmm+KfvJK9meqaRq6Md7Sw1r8Ys+qBzNhkpwGeXN4e7RCp64Q@mail.gmail.com> <CADmm+Kf-MSuDGFnH7OVSZBrKR9z-Eta9_Y90-zDNnLSrkqYVcg@mail.gmail.com>
From: Niclas Hedhman <hedhman@gmail.com>
Date: Sun, 9 Apr 2017 07:22:20 +0800
Message-ID: <CADmm+Ke_3hULHJbGS0EYwtturkWZGA9pDa918g63uzPM7a_L=Q@mail.gmail.com>
Subject: Re: javax.script
To: dev@polygene.apache.org
Content-Type: multipart/alternative; boundary=001a113cc7108eb4f1054cb003c2
archived-at: Sat, 08 Apr 2017 23:22:28 -0000

--001a113cc7108eb4f1054cb003c2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Ok, I will try to figure out if single compile per composite type is
possible. My initial finding is that it is not.

Expect it to complete today.

On Apr 8, 2017 20:58, "Paul Merlin" <paulmerlin@apache.org> wrote:

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 =C3=A9crit :
> 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 an=
y
> 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 (=3D=3Dslow?)
>
> 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 othe=
r
> 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

--001a113cc7108eb4f1054cb003c2--