[[Set]] and inherited readonly data properties

Mark S. Miller erights at google.com
Wed Mar 26 13:20:27 PDT 2014

This mistake is my single biggest regret from the ES5 days. We had a chance
to get this right when it would have been rather painless and we blew it.

Although it can no longer be fixed without a lot of pain, I still think the
pain of not fixing it will be greater. However, I'm sick of arguing about
this one and have become resigned to using tamperProof <
rather than freeze. Using tamperProof rather than freeze, your example will

If enough others become convinced that this still can and should be fixed,
we should still fix this. However, someone else would need to volunteer to
champion it within TC39. Any volunteers?

On Wed, Mar 26, 2014 at 11:48 AM, Allen Wirfs-Brock
<allen at wirfs-brock.com>wrote:

> On Mar 26, 2014, at 11:24 AM, Jason Orendorff wrote:
>    "use strict";
>    function Pony() {}
>    Object.freeze(Object.prototype);
>    Pony.prototype.toString = function () { return "Pony"; };
> The last line here throws a TypeError in ES5 and ES6.*  Can we change
> it? To me, it stands to reason that you should be able to freeze
> Object.prototype and not break your other code, as long as that code
> doesn't actually try to modify Object.prototype.
> This bit some Mozilla hackers in <http://bugzil.la/980752>.
> Compatibility: Changing from throwing to not-throwing is usually ok.
> In addition, I don't think Chrome implements this TypeError. So
> presumably the web can't be depending on the exception.
> This change would not just eliminating a throw in strict mode.  It is also
> change sloppy mode behavior where such assignments have been silently
> ignored since ES1. It would be a fundamental change to the meaning of the
> [[Writable]] property attribute.
> see
> http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake (and
> links from that page)
> also see the recent discussion at
> https://github.com/getify/You-Dont-Know-JS/issues/91#issuecomment-38702332
> So far we have not been able to reach a consensus on changing this.  I
> don't know whether report actually adds any new information or whether it
> will help develop a consensus.
> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140326/2333179e/attachment.html>

More information about the es-discuss mailing list