A Precedent

Brendan Eich brendan at mozilla.com
Fri Apr 12 13:34:33 PDT 2013


Andrea Giammarchi wrote:
> Alex, I wrote that with best intents. I have the incredible ability to 
> transform any thread in a flame so for this mailing list sake is 
> better, as I've written already, to be as far away as possible (I keep 
> watching threads though).
At least read up on the topic. A "site:mail.mozilla.org es-discuss 
__proto__ __defineGetter__" search is a good starting point.

https://mail.mozilla.org/pipermail/es-discuss/2013-March/029341.html

(a reply to you asking the same thing you again ask, in March -- did you 
not read the reply last month?)

This leads directly (at bottom) to

https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-29.md#45-why-standardizing-on-__proto__-and-not-__definegsetter__-__lookupgsetter_

wherein Rick recorded:


    4.5 Why standardizing on |__proto__| and not |__define(G|S)etter__|,
    |__lookup(G|S)etter__|?

(Based on a recent es-discuss thread)

Why |__proto__| normative mandatory in ES6 but no |__define/lookup...| is:

 1. |__proto__| much more used on the mobile (iOS WebKit-first) web, no
    equivalent interop pressure for __d/l.
 2. ES5 is in all new/evergreen browsers and it has standard APIs
    supplanting |__d/l| but nothing for writing to |__proto__|.

Therefore |__proto__| gets standardized, |__d/l| do not.

Rationale for not adding Object.setPrototypeOf 
https://mail.mozilla.org/pipermail/es-discuss/2012-May/022904.html


        <https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-29.md#conclusionresolution-3>Conclusion/Resolution

Consensus that |__define(G|S)etter__|, |__lookup(G|S)etter__| will not 
be standardized, nor added to an Appendix.


    <https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-29.md#48-refactored-new-operator-and-the-create-method>


> AFAIK, Chromium might solve this soon so no need to fork it?
> http://code.google.com/p/v8/source/detail?r=14139

No, because the setter will be poisoned, per

> I understand early adopters and the fact is unfortunately in too many 
> browsers now as de-facto mess due all problems described before but I 
> don't understand the answer of TC39
>
> __defineGetter__
> __defineSetter__
> __lookupGetter__
> __lookupSetter__
>
> have been used and adopted by all browsers but IE for years and the 
> **right** answer from TC39 has been deprecating these and proposing
>
> Object.defineProperty(get/set)
> and
> Object.getOwnPropertyDescriptor()
>
> It is still not too late to propose Object.setPrototypeOf(target, 
> proto):target and keep the __proto__ status deprecated 'cause I cannot 
> believe many of us are waiting for Object.prototype.__proto__ to be 
> removable so that the problem will be solved at the root.

We've been over this many times, as noted above often in *direct 
replies* to your posts.

Are you not reading the replies, or forgetting them?

/be


More information about the es-discuss mailing list