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 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
