>From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] >On Behalf Of Maciej Stachowiak
>>In case this experiment does run into problems, what do you think about >>Allen's proposed restriction: "That [[Prototype]] is guaranteed not to change >>on an object for which [[Extensible]] is false."? This takes care of the >>security issue I'm concerned about and won't break any old code. >I think that would be a reasonable restriction to apply in light of freezing. >I think it would be weird for the spec to require it without specifying >__proto__ in the first place, but I think it would be a good idea for browsers >that implement mutable __proto__ to do it, if other options do not pan out. >Perhaps to avoid the somewhat nonsensical state of imposing conformance >requirements on features that the spec doesn't actually define, ideas of this >sort could be provided in the form of non-normative implementation advice. I agree that it is problematic to spec. things related to extensions that are not part of the spec. In this particular case I wouldn't talk about __proto__ at all. What I would do is specify that the value of an object's [[Prototype]] internal property many not be modified if the value of its [[Extensible]] property is false. 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). Personally, while it is a quite plausible embellishment of what we already have specified, I think it is very late for such additions and I'm somewhat skeptical of the actual impact of such prophylactic requirement on implementers who think they have a good idea that collides with the restriction. Allen _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
