super.prop assignment can silently overwrite non-writable properties

Caitlin Potter caitpotter88 at gmail.com
Mon Apr 20 19:42:12 UTC 2015


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 <jason.orendorff at gmail.com> wrote:
> 
> On Mon, Apr 20, 2015 at 12:44 PM, Allen Wirfs-Brock
> <allen at wirfs-brock.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list