Le 26/03/2014 19:24, Jason Orendorff a écrit :
>      "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.
It looks like the "override mistake".
http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake
Mark Miller agrees with you. I agree with you.
The consensus is apparently that it is the desired behavior.
Threads on the topic:
https://mail.mozilla.org/pipermail/es-discuss/2012-January/019562.html
https://mail.mozilla.org/pipermail/es-discuss/2013-March/029414.html
(there might be meeting notes on this topic too)

> 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.
I can observe it does in Chrome 33. (the REPL doesn't consider the "use 
strict"; wrap in an IIFE to see the error being thrown)

David

> 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.

It looks like the "override mistake".
http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake
Mark Miller agrees with you. I agree with you.
The consensus is apparently that it is the desired behavior.
Threads on the topic:
https://mail.mozilla.org/pipermail/es-discuss/2012-January/019562.html
https://mail.mozilla.org/pipermail/es-discuss/2013-March/029414.html
(there might be meeting notes on this topic too)

> 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.

I can observe it does in Chrome 33. (the REPL doesn't consider the "use 
strict"; wrap in an IIFE to see the error being thrown)