github at esdiscuss.org (2013-07-12T02:26:54.614Z)
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 > > **Conclusion/Resolution** > > 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? /be
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