[[Set]] and inherited readonly data properties

[Andrea Giammarchi]

Mark I agree that writable:false, once inheritance is in the middle, is the
worst thing ever shipped in ES5 but once again this `tamperProof(obj)` you
keep mentioning won't work with IE9 Mobile (low share), webOS
(disappearing), and Android 2.3.X and lower (30% of Android web share) so
it's a not so good solution.

What is good is that as I've made `protoypal.Class` [1] function compatible
with `Object.freeze(Object.prototype)` so that your `Point` example would
be:

```javascript
Object.freeze(Object.prototype);

var Class = require('prototypal').Class;

var Point2D = Class({
  constructor: function (x, y) {
    this.x = x || 0;
    this.y = y || 0;
  },
  toString: function () {
    return '[object Point2D]';
  }
});

'' + new Point2D; // [object Point2D]
```

anyone else could learn how to use `Object.defineProperty` which does not
suffer from frozen prototypes.

Long story short, `writable:false` is annoying, but not that difficult to
avoid for "classes" like architectures.

Cheers




[1] http://github.com/WebReflection/prototypal



On Mon, Mar 31, 2014 at 5:08 PM, Mark Miller <erights at gmail.com> wrote:

> 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.giammarchi at 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 <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
>>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Text by me above is hereby placed in the public domain
>
>   Cheers,
>   --MarkM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140331/6aad89b0/attachment.html>