Proxies: wrong "receiver" used in default "set" trap

Tom Van Cutsem tomvc.be at gmail.com
Thu Dec 20 04:04:21 PST 2012


2012/12/20 Andreas Rossberg <rossberg at google.com>

> On 20 December 2012 11:09, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
>
>> Currently, that test is performed in step 5.b. by testing whether the
>> "current" object we are visiting in the proto chain O is the Receiver
>> object. At first sight, this is a rather weird way of deciding between
>> update vs. addition. We can get away with this test because we've just
>> queried the O object for an own property (ownDesc). Hence, if O ===
>> Receiver, then we know Receiver already has the same property and we must
>> update, rather than add.
>>
>> In the presence of proxies, this test is no longer valid, as Receiver may
>> be a proxy for O.
>>
>> The right fix (at least, it feels like the obvious right fix to me), is
>> not to test whether O === Receiver, but rather just let the algorithm
>> explicitly test whether the Receiver object already defines an own property
>> with key P, to decide between update vs. addition:
>>
>> replace step 5.b with:
>> 5.b Let existingDesc be the result of calling the [[GetOwnProperty]]
>> internal method of Receiver with argument P.
>> 5.c If existingDesc is not undefined, then
>>   ... // same steps as before
>>
>> Now, for normal objects, this test is redundant since existingDesc and
>> ownDesc will denote the same property.
>>
>
> ...or existingDesc is already known to be undefined, in the case where
> Receiver !== O, right?
>

Yes. If ownDesc is undefined, we never even reach step 5.b.

If Receiver !== O we previously added a new data property.
With the new test, if existingDesc is undefined, we also add a new data
property.

So the behavior is consistent.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121220/0e8a28b9/attachment.html>


More information about the es-discuss mailing list