Oh — he’s right, ValidateAndApplyPropertyDescriptor won’t throw in the example case, because the old descriptor is configurable. That’s kind of weird.
> On Apr 20, 2015, at 3:39 PM, Jason Orendorff <[email protected]> > wrote: > > On Mon, Apr 20, 2015 at 12:44 PM, Allen Wirfs-Brock > <[email protected]> wrote: >>> In the spec, 9.1.9 step 4.d.i. is where `super.prop = 2` ends up, with >>> O=X.prototype. >> >> 4.d.1 doesn't set the property, it just comes up with the property >> descriptor to use, if the `Receiver` does not already have a corresponding >> own property. >> >> 5.c+5.e checks if the corresponding own property actually exists on the >> `Receiver`. >> >> If it already exits then it does a [[DefineOwnProperty]] that only specifies >> the `value` attribute. This should respect the current `writable` attribute >> of the property and hence reject the attempt to change the value. > > I agree with all of this, except I don't see where the attempt is > rejected. Since the property is configurable, I think > [[DefineOwnProperty]] succeeds. > > The property is still non-writable afterwards. Only the value changes. > > So this isn't breaking the object invariants: the property in question > is configurable, so it's OK (I guess) to change the value. It's just > surprising for assignment syntax to succeed in doing it. > > -j > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
