so it's not just me ... let's see if I can contribute a bit here with my thoughts ( I think I cannot edit that page )<div><br></div><div><br></div><div><div>==== Why it's bad for efficiency ====</div><div><br></div>
<div>Frozen objects can be considered similar to C structs and optimized by ES engines as such.</div><div>Being prototypal inheritance based on objects, sharing a well defined and frozen shape in the __proto__ level could only brings advantages in therms of performances.</div>
<div><br></div><div><br></div><div>==== Why it's inconvenient ====</div><div><br></div><div>Defaults can be defined through __proto__ properties.</div><div>Once we have a prototype that we would like to ensure/grant as it is and with those defaults, there's no mechanism in current ES specs able to do this.</div>
<div>A classic `{name:"", age:0}` human like prototype could be reused to `Object.create(human)` related objects where all of them will surely start aging from zero and will have a name as soon as created. All simple mechanism to interact with this instance and its inherited properties will be broken.</div>
<div><code javascript></div><div>  var human = Object.freeze({name: "", age: 0});</div><div>  var me = Object.create(human);</div><div>  </div><div>  // unable to have a name</div><div>  <a href="http://me.name">me.name</a> = "Andrea";</div>
<div>  </div><div>  // after a year, unable to age</div><div>  me.age++;</div><div><br></div><div>  [<a href="http://me.name">me.name</a>, me.age];  // "", 0</div><div></code></div><div><br></div><div><br>
</div><div>==== Why it's bad for security ====</div><div><br></div><div>There is no way to use in a meaningful way frozen objects when it comes to security and inheritance.</div><div>Properties with values will make normal objects interaction hard.</div>
<div>We don't want to end up with similar hacks to be able to define properties:</div><div><code javascript></div><div>  function setIfPossible(obj, key, value) {</div><div>    var descriptor = Object.getOwnPropertyDescriptor(</div>
<div>      obj, key</div><div>    );</div><div>    var set = descriptor.hasOwnProperty("value");</div><div>    if (set) {</div><div>      Object.defineProperty(obj, key, {</div><div>        enumerable: descriptor.enumerable,</div>
<div>        writable: true,</div><div>        configurable: true,</div><div>        value: value</div><div>      });</div><div>    }</div><div>    return set;</div><div>  }</div><div>  </div><div>  if (!setIfPossible(me, "age", me.age + 1)) {</div>
<div>    throw "I am Dorian Gray";</div><div>  }</div><div></code></div><div>Accordingly, in order to avoid these problems developers will not use Object.freeze to ensure prototype defaults or, if used, the feeling that properties are not writable and so defaults are safe when simply passing through `Object.defineProperty()` will make the overwrite possible.</div>
<div>As summary, this is a security limit and problem rather than an improvement over most common prototypal use cases.</div><div><br></div><div><br></div><div>==== How bad would fixing it be for legacy compatibility? ====</div>
<div><br></div><div>AFAIK there is no legacy based on this assumption. First of all because 90% of libraries are using ES3 code, secondly because nobody would like to have on purpose this behavior which brings nothing.</div>
<div>If a constructor should ensure immutable properties, inherited included, it will freeze the instance before returning it by itself.</div><div>Also the inconsistency is that assigning a property pass through the prozen __proto__ but adding properties not defined in the not extendible __proto__ does not prevent any operation.</div>
</div><div><br></div><div><br></div><div><br></div><div>How should it be, in my opinion:</div><div><br></div><div>if defineProperty is allowed, obj.property = value should be allowed too if the __proto__.property descriptor contains the *value* field.</div>
<div><br></div><div>br</div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 6, 2012 at 7:50 PM, Brandon Benvie <span dir="ltr"><<a href="mailto:brandon@brandonbenvie.com" target="_blank">brandon@brandonbenvie.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I recall now that there's actually a strawman about this. <a href="http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake" target="_blank">http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake</a>
</blockquote></div><br></div>