2012/12/20 Andreas Rossberg <rossb...@google.com> > On 20 December 2012 11:09, Tom Van Cutsem <tomvc...@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
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
