Isn't such a behavior of Object.freeze potentially future-hostile? One of
the reasons why with went away was that adding new methods to standard
prototypes could break the code (what happened with
Array.prototype.values). But if Object.freeze is used to prevent others
from messing with builtins, as a way of defensive programming, the effect
could be the same. Imagine the code:

Object.freeze(Object.prototype);
// ...
var a = {};
a.field = 2;

If now some future ES version adds Object.prototype.field, this code starts
to break.

It seems that in its current definition freezing builtins should be
discouraged as future-hostile. Am I getting something wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140331/e717e80c/attachment.html>

Isn't such a behavior of Object.freeze potentially future-hostile? One of
the reasons why with went away was that adding new methods to standard
prototypes could break the code (what happened with
Array.prototype.values). But if Object.freeze is used to prevent others
from messing with builtins, as a way of defensive programming, the effect
could be the same. Imagine the code:

```js
Object.freeze(Object.prototype);
// ...
var a = {};
a.field = 2;
```

If now some future ES version adds Object.prototype.field, this code starts
to break.

It seems that in its current definition freezing builtins should be
discouraged as future-hostile. Am I getting something wrong?