super.prop assignment can silently overwrite non-writable properties

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Apr 21 00:54:33 UTC 2015


On Apr 20, 2015, at 5:28 PM, Caitlin Potter wrote:

> It makes perfect sense for Object.defineProperty, but maybe not so much sense for PutValue(). One idea was to just add an `return false if existingDescriptor.[[Writable]] is false.` Before receiver.[[DefineOwnProperty]]()`. 

yes, something like that.  I'm working on the fix right now.  But it's probably more complicated then that.  Consider what happens if the Receiver already has an like-named own accessor property...

I think in that case it needs to fail. Otherwise, the current algorithm will turn the accessor property into a data property, which seems even more bogus then the ignore writable behavior.

Allen







> 
>> On Apr 20, 2015, at 8:17 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> 
>> 
>>> On Apr 20, 2015, at 12:42 PM, Caitlin Potter wrote:
>>> 
>>> Oh — he’s right, ValidateAndApplyPropertyDescriptor won’t throw in the example case, because the old descriptor is configurable. That’s kind of weird.
>> 
>> It is kind of weird, but that was what TC39 decided on back when ES5 was being developed.  The logic was that if a property is configurable then it is possible to change all of its attributes  by performing a [[DefineOwnProperty]] with a complete property description.   Because of that possibility, all changes made via a partial property descriptor are also accepted.  In other words:
>> 
>> var o = Object.create(null, {x:{value: 0, writable: false, enumerable: true, configurable:true}});
>> Object.defineProperty(o,' x', {value:2});
>> console.log(o.x); //2
>> 
>> The define property above is allowed because it could have been replaced with the sequence :
>> Object.defineProperty(o,'x', {writable: true});
>> Object.defineProperty(o,'x', {value: 2, writable: false});
>> 
>> or even by:
>> delete o.x;
>> Object.defineProperty(o,'x', {value: 2, writable: false, enumerable: true, configurable: true};)
>> 
>> hence, we might as well accept the single line version.
>> 
>> In retrospect, perhaps not such a good idea. 
>> 
>> Allen
>> 
>> 
>> 
> 



More information about the es-discuss mailing list