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.


(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


wherein Rick recorded:

    4.5 Why standardizing on |__proto__| and not |__define(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 


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


> 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?


More information about the es-discuss mailing list