On Dec 10, 2008, at 10:14 AM, Johan Compagner wrote:
ok scripts seems to be stateless yes
Problem is we cant use that, we really have functions that we want to
execute like this:
Object o = f.call(cx, scope, thisObject, args);
and then that function is called with the args we want to give it..
this is not possible with a Script because a script only has:
compileString.exec(cx, scope);
as you can see almost the same thing.. except that a function has a
bit more
state pushed to it
You can call a function from a script:
NativeObject script = (NativeObject)script.exec(context, scope);
NativeObject params = new NativeObject();
params.put("request", params, req);
params.put("response", params, resp);
Object[] args = {params};
NativeObject result =
(NativeObject)ScriptableObject.callMethod(script, "myFunc", args);
best,
-Rob
So why is there a difference in a function or a script?
Both should be the same thing and both use the state that is given
to the
call or exec method.
johan
On Wed, Dec 10, 2008 at 15:56, Johan Compagner
<[EMAIL PROTECTED]> wrote:
ahh but we use:
Function f = cx.compileFunction(scope, source.toString(),
sp.getDataProviderID(), 1, null);
as you can see there there is a scope
and that gives us a compiled function class with a scope.
I will see if we can work with just Script objects
problem is that we use Function objects everywhere in our code. not
Scripts.
johan
On Wed, Dec 10, 2008 at 15:53, Attila Szegedi <[EMAIL PROTECTED]>
wrote:
On 2008.12.10., at 15:15, Johan Compagner wrote:
hmm
i now checked a compiled script what kind of properties it have.
First problem that i see is that it has a parentScopeObject that
is the
scope that it used to compile against
Neither Context.compileScript() nor Context.compileReader take a
scope
parameter; and Rhino doesn't conjure them from thin air when
compiling a
script, so there's no such thing as a "scope to compile against".
Compilation is independent of any scope.
Problem is that that is a scope really specific to one client.
So it really shouldnt hold on to that one. I can try to set that
one to
null i guess.
besides that it also has the prototype object. And that prototype
object
doesnt have really stuff from our own code
Well, Script itself doesn't need to be a Scriptable, so again, why
would
it need a prototype?
Actually, it *can* be a Scriptable too -- interpreted scripts are
in fact
instances of InterpretedFunction, but that's an implementation
detail.
During the course of execution (within Script.execute()) you can't
obtain a
reference to the Script object itself, so the JS code can't affect
its state
in any way (and Rhino runtime also most certainly won't).
Also, note I mentioned interpreted scripts above -- I don't know
what are
compiled Script compiled into -- maybe they too implement Function
and or
Scriptable, but I'd be inclined to believe this is solely an
implementation
artifact -- Scripts are really not much different from being a top-
level
anonymous function, so using the same Java class to represent them
as is
used to represent functionscan be justifiied.
Again, I'd like to hear Norris' opinion, but I just can't imagine
Script
objects to have shared mutable state.
Attila.
--
home: http://www.szegedi.org
twitter: http://twitter.com/szegedi
weblog: http://constc.blogspot.com
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
