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?
And you execute something twice?
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
