On Dec 10, 2008, at 10:41 AM, Johan Compagner wrote:
Question is Why do we need such a way around everything?
why does exec on a script return a native object which is again a
script?
(or is that the same script?)
You overwrite the variable script?
Yes, my mistake. it should have been something like:
NativeObject instanceScript =
(NativeObject)myCachedScript.exec(context, scope);
And you execute something twice?
I executed it once to get the script, then called a function in the
script.
I am new too -- wish there were more docs/examples...
Also, this might have something to do with how I write the JS, e.g.
(function() {
var privateFunc = function() {...}
return {
publicFunc: function() {...},
publicFunc2: function() {...}
}
})();
So the script executes immediately (that is what the last parans makes
happen) and returns my public functions.
best,
-Rob
I dont know all the ins and outs ofcourse but until now i dont know
why
there is such a difference between a script and a function compile
wise
As far as i see it shouldnt have to be.
johan
On Wed, Dec 10, 2008 at 16:34, Robert Koberg <[EMAIL PROTECTED]> wrote:
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
_______________________________________________
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
