Another de-facto insecurity we need to fix in ES5

Allen Wirfs-Brock Allen.Wirfs-Brock at microsoft.com
Thu Jun 18 09:15:09 PDT 2009


>-----Original Message-----
>From: Brendan Eich [mailto:brendan at mozilla.com]
>
>> BTW, I haven't yet perceived that we have consensus on putting this
>> into ES5.  My interpretation of  Brendan's initial comments on the
>> matter was that he was opposed to it for ES5.  (I'm sure he'll let
>> us know whether or not that is correct).
>
>It's late in the game, but a sentence about [[Prototype]] seems
>doable. I defer to you on this, since you're Editor and it'll fall
>upon you to draft the change.
>

OK, I'll put it in.  Here is what I am inserting into section 8.6.2 following the paragraph about [[Prototype]] that comes immediately after table 4:

Every ECMAScript object has a Boolean-valued [[Extensible]] internal property that controls whether or not named properties may be added to the object. If the value of the [[Extensible]] internal property is false then additional named properties may not be added to the object.  In addition, if [[Extensible]] is false the value of the [[Prototype]] internal property of the object may not be modified.  Once the value of an [[Extensible]] internal property has been set to false if may not be subsequently changed to true.

NOTE
This specification defines no ECMAScript language operators or built-in functions that permit a program to modify an object's [[Prototype]] internal property or to change the value of [[Extensible]] from false to true. Implementation specific extensions that modify [[Prototype]] or [[Extensible]] must not violate the invariants defined in the preceding paragraph.



Notice that I also made sure that [[Extensible]] cannot go from false to true which was also previously unstated in the specification.
Allen


More information about the es-discuss mailing list