For a non-prototypical object, obj, tamperProof(obj) is the same thing as
freeze(obj).
On Mon, Mar 31, 2014 at 3:56 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> 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 <erig...@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.go...@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@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>>
>> --
>> Cheers,
>> --MarkM
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
