On 20 December 2012 11:09, Tom Van Cutsem <[email protected]> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
