Domenic Denicola wrote:
-----Original Message-----
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Brendan Eich
Sent: Saturday, May 26, 2012 15:08
New syntax may some day clean all this up but the short path wins and
it'll be hard to displace. Let's be realistic. I agree we should,
assuming classes make it, support DOM subclassing. That is good but it
won't relieve DOM implementors from supporting __proto__.
Is there a parallel to be drawn with __(define|lookup)(Getter|Setter)__, or is
__proto__ different? I quite liked Allen's blog post about why IE decided to
never support them [1]. Following that reasoning seems to lead to specifying
Object.setPrototypeOf as a __proto__ replacement,
No. First, you missed Mark's argument that I paraphrased against a
per-frame (window, global context) static method, which David Bruant
acknowledged in this thread just eight messages back:
Once we're at it, for the sake of completeness there is probably no
harm in adding a Reflect.setPrototype at this point, is there?
There is, just as there's a cost to Object.setPrototypeOf (the obvious
place to put it to match Object.getPrototypeOf from ES5). Mark pointed
out that he'd have to delete that static method too, and from every
frame that might run SES code. But when mashing up SES and non-SES
code, it would be better not to break the non-SES code by such deletion.
Having only the SES environment's Object.prototype.__proto__ to delete
is better.
And I realize that the new hazard is not due to __proto__ in itself, but
rather to the capability of arbitrarily changing the prototype of an
object, so adding an Object.setPrototypeOf really is a step backward.
David
--- end quote ---
Second, Allen's rationale, made while he was at Microsoft (no comment),
addressed particular extensions with particular arguments. We need to
look at the cases:
* Getters and setters were more often, and better, used by the get/set
object literal syntax. That's in ES5 without change.
* __{define,lookup}{G,S}etter__ could indeed have been standardized but
they were not so often used as __proto__ is.
Indeed it was Microsoft's 2005-era "Atlas" AJAX knock off used by live
maps that made use of these SpiderMonkey extensions, to dress up non-IE
DOMs as if they were the IE DOM -- which assumes non-IE browsers have
these __define/lookup... methods. This forced Apple and Opera to
reverse-engineer and implement rapidly, but it did not have any effect
on IE, of course.
Finally, everyone on TC39 wanted more than these old APIs provided. That
led to ES5's meta-programming API under Object.
* __proto__ is widely used, especially on "the mobile web", which is not
"the web" that many who focus on desktop see or think of when authoring.
Thus Zepto's use of __proto__, but not of __define/lookup....
So between __proto__ being much more in demand, __define/lookup not
being so much in demand, get/set syntax winning without change, and
especially the "mobile web" content divergence due to WebKit, the same
rationale for rejecting __define/lookup... did not and *does not* apply
to rejecting __proto__.
You can't treat all __-affixed extensions the same, in short. They're
neither all cursed nor all blessed. Usage in the market matters.
/be
and hoping library authors follow suit in switching to that from __proto__,
just like they did for the property API.
http://blogs.msdn.com/b/ie/archive/2010/08/25/chakra-interoperability-means-more-than-just-standards.aspx
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
