That's pretty much true. In most cases, you're better of using static
helpers
ScriptableObject.putProperty(object, "propertyName", value) or
ScriptableObject.putProperty(object, propertyIntIndex, value)
Attila.
On Oct 8, 2008, at 11:42 PM, Peter Michaux wrote:
> 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
