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
