> -----Original Message----- > From: [email protected] [mailto:es-discuss- > [email protected]] 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
