Kris,
Ok. The example you show below makes sense. It seems the JavaScript
interpreter calls the "put" method on the "o" object and since "o"
doesn't have a setter for "a", "o" delegates the request to it's
prototype object sending "o" as the "start" parameter. That way the
prototype can set slot "a" on "o" using the prototype's put method.
Seem correct?
That would mean that when the interpreter calls the "put" method of a
Scriptable object, "this" and "start" will always be the same,
correct? I think this is probably what needs mentioning in the
documentation if it is correct.
When an object calls another object's "put" it can send anything it
likes as the "start" parameter. So from the perspective of the
Scriptable interface, there isn't anything particularly 'start' about
the "start" parameter. It is just some object and is called start
because its motivation for existence is to implement the JavaScript
semantics.
Peter
On Wed, Oct 8, 2008 at 12:15 PM, Kris Zyp <[EMAIL PROTECTED]> wrote:
> Peter,
> I believe the primary purpose for this design is to preserve the
> correct |this| for setters. For example:
> p = {set a(value){ console.log(this.id) }, id: 1};
> P = function(){};
> P.prototype = p;
> o = new P;
> o.id = 2;
> o.a = 3;
> This should log the value 2 (not 1), and so basically the start
> parameter is passed around with the put calls as
> ScriptableObject.getProperty(obj,name) traverses the prototype chain
> so if and when a setter is hit it can be called with the correct |
> this|.
> Kris
>
> On Oct 8, 10:26 am, "Peter Michaux" <[EMAIL PROTECTED]> wrote:
>> The documentation for Scriptable "put"
>>
>> http://www.mozilla.org/rhino/apidocs/org/mozilla/javascript/Scriptabl...)
>>
>> describes the second parameter "start"
>>
>> > Note that if a property a is defined in the prototype p
>> > of an object o, then evaluating o.a = 23 will cause set
>>
>> What does "set" mean specifically? I don't think "set" is referring to
>> some ECMA property that are usually in double brackets.
>>
>> > to be called on the prototype p with o as the start
>> > parameter. To preserve JavaScript semantics, it is the
>> > Scriptable object's responsibility to modify o.
>>
>> "the Scriptable object" refers to "o" or "p"? They could both be
>> ScriptableObject instances, yes?
>>
>> I don't understand what the above is trying to say. To me, evaluating
>> "o.a = 23" should set a value on "o" itself and not on o's prototype.
>> If objects "n" and "o" both share the same prototype "p", then
>> evaluating "o.a = 23" should not set the value "a" on prototype "p" as
>> that would affect "n". I imagine that Rhino is doing the right thing
>> but the above documentation seems misleading/confusing to me.
>>
>> > This design allows properties to be defined in prototypes
>> > and implemented in terms of getters and setters of Java
>> > values without consuming slots in each instance.
>>
>> Equally confused by this second paragraph.
>>
>> If someone explains what the documentation is trying to explain, I'll
>> submit a documentation patch.
>>
>> Thanks,
>> Peter
>
> _______________________________________________
> 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
