[[Set]] and inherited readonly data properties

Mark S. Miller erights at google.com
Mon Mar 31 14:47:12 PDT 2014

Yes. This cure is worse than the disease. Object.freeze is important for
defensiveness for at least the reasons you state. The problem isn't just
new assignments like a.field = .... It is also old assignments like

function Point(....) {....}

Point.prototype.toString = function() {....}; // fails

Unless the committee revisits the override mistake, which seems unlikely,
the only way to cope that I know of is to use tamperProof(obj) where you
would have used freeze(obj).

Not fixing the override mistake was our biggest mistake in ES5. My
apologies for not raising the alarm until late, and not making the case
forcefully enough before it was too late. This is my single biggest regret
of all the time I've spent on TC39.

On Mon, Mar 31, 2014 at 2:37 PM, Michał Gołębiowski <m.goleb at gmail.com>wrote:

> 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?
> _______________________________________________
> 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/20140331/da53f5ff/attachment.html>

More information about the es-discuss mailing list