Thx for thinking with me :)
But i already found a problem why functions really have to have there own
scope.. (now i think scripts wont really work for use at all)
we have this kind of structure
globalscope
-> subscope1
->function1
-> subscope2
->function2
now function1 does this:
subscope2.function2()
then if function2() is executed it really should have the subscope2 as its
parent scope..
Because else it wouldnt work for use if it also would run in the subscope1
of the function1
So functions for us really has to have internal scope. I have no idea how
this would work for scripts
if i had the same setup with scripts?
What scope would then scripts2 use?
Or there should be somewhere code that knows that function2 is a child of
subscope2 and that subscope2 would then be
automatically the scope in the call() method. But as far as i see that
doesnt happen it seems to do that for the thisObject:
public static Object callProp0(Object value, String property, Context
cx, Scriptable scope)
{
Callable f = getPropFunctionAndThis(value, property, cx);
Scriptable thisObj = lastStoredScriptable(cx);
return f.call(cx, scope, thisObj, ScriptRuntime.emptyArgs);
}
thisObject == is the right object/scope
But the scope is still the one from 1
Now i dont know exactly what th thisObject does again.
johan
On Wed, Dec 10, 2008 at 16:53, Robert Koberg <[EMAIL PROTECTED]> wrote:
>
> 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
