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

Andreas Rossberg rossberg at google.com
Thu Dec 20 03:37:26 PST 2012


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?


>  But that redundancy is harmless, just as in ES5 [[Put]] it was redundant
> to call both [[GetProperty]] and [[GetOwnProperty]] on the same object. In
> the fast path, engines will not follow this algorithm anyway. If Receiver
> is a proxy, then the difference matters and the proxy will be able to
> intercept the call to [[GetOwnProperty]] (which is what makes this revised
> algorithm work in the presence of proxies).
>

 Sounds good to me.

/Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121220/366b5198/attachment.html>


More information about the es-discuss mailing list