Subclassing built-in constructors

Domenic Denicola domenic at domenicdenicola.com
Sat May 26 12:34:04 PDT 2012


> -----Original Message-----
> From: es-discuss-bounces at mozilla.org [mailto:es-discuss-
> bounces at 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, 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



More information about the es-discuss mailing list