commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Date Sat, 01 Aug 2009 04:21:41 GMT
On 01/08/2009, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> On Fri, Jul 31, 2009 at 9:42 PM, sebb<sebbaz@gmail.com> wrote:
>  > On 31/07/2009, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>  >> On Thu, Jul 30, 2009 at 10:54 PM, sebb<sebbaz@gmail.com> wrote:
>  >>  > I've finished the implementation of a basic Jexl ScriptEngine for JSR-223.
>  >>  >
>  >>
>  >> <snip/>
>  >>
>  >>  Cool, thanks.
>  >>
>  >>  mvn package failed for me (w/ Sun 1.6), committed fix in r799750.
>  >
>  > Ah.
>  >
>  > However, I think the fix may be wrong, it should probably be a
>  > (String) cast instead, and should probably ignore the put if it's not
>  > a String.
>  >
>
> <snip/>
>
>  Ah, saw the related BSF bug you logged.
>
>
>
>  >>  I'll take a look at the code itself in a few minutes.
>  >>
>  >>
>  >>
>  >>  > Several items remain to be resolved:
>  >>  >
>  >>  > The current implementation only has direct access to the ENGINE_SCOPE
bindings.
>  >>  >
>  >>  > If we wish to give direct access to GLOBAL_SCOPE, how should this be
managed?
>  >>  > Perhaps use a name prefix to indicate that the variable is intended to
>  >>  > be global?
>  >>  >
>  >>
>  >> <snap/>
>  >>
>  >>  No. The engine scope is nearest, so on read or update, check engine
>  >>  first and global second. No prefixes.
>  >>
>  >
>  > That's fine, but how does one create an entry in the global table?
>  > Or is that not allowed?
>  >
>
> <snap/>
>
>  Thats the job of the javax.script environment. More specifically, the
>  ScriptEngineManager will inject the global scope bindings into the
>  ScriptEngine. We just have to heed those -- IOW, anything other than
>  put(), putAll() and remove() in the JexlContextWrapper class you have
>  should refer to the union of the engine and global scopes. For methods
>  where orders matters i.e. containsKey/Value() and get(), engine scope
>  beats global. Finally, IMO the clear() implementation should remain
>  as-is and not touch the global scope.
>

Yes, one can now set up the global scope with some key-value pairs;
these are now readable/writable by a JEXL script. However, it's not
currently possible to create a global key. If put() uses a key that is
not currently present, it will generate an engine-scope variable.

Seems to me if we allow read/write/delete of global variables by a
JEXL script, then we should also allow creation of global variables.
This would allow different scripts (possibly different languages) to
communicate via the global area.

How to allow this? One method would be to use a naming convention.
Another might be to have a global-shift key - if the key is set, then
apply changes to the global scope only, for example:

localvar=123;
set_scope="global"
globalval=456;
set_scope="local"

A bit of a hack, but do-able.

The ScriptEngine implementation could even make certain classes of
global variables read-only, for example System_OUT etc. by disallowing
changes to them.

>
>  >>
>  >>  > As far as I can tell, Jexl does not have built-in output statements.
>  >>  > It might be useful to pre-define some variables to make this easier;
>  >>  > e.g. we could define OUT as System.out, which would allow the use of
>  >>  > OUT.println()
>  >>  >
>  >>
>  >> <snip/>
>  >>
>  >>  Sounds reasonable. But make the name obscure, OUT would be easily trampled
IMO.
>  >>
>  >
>  > Yes, OUT is a bit short.
>  > How about System_OUT ?
>  > Or we could reserve a Jexl-specific prefix; this would be useful when
>  > using multiple languages with the same ScriptEngineManager.
>  >
>
> <snip/>
>
>  Slight preference towards a JEXL-specific prefix.
>
>  -Rahul
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message