[[Set]] and inherited readonly data properties

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Mar 31 15:56:44 PDT 2014


my 2 cents, I think `Object.freeze()` is OK if used with objects that
should be frozen, most likely instances, not prototypes.

What's future and environmentally hostile is actually freezing the
`Object.prototype` not because of `freeze()`, rather because the same way
we should not extend to not break other libraries code, we should not feel
the owner of the `Object.prototype` freezing it.

I find both cases very obtrusive.

Best Regards



On Mon, Mar 31, 2014 at 2:47 PM, Mark S. Miller <erights at google.com> wrote:

> 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
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140331/c08f09de/attachment.html>


More information about the es-discuss mailing list