domenic at domenicdenicola.com (2013-08-25T00:52:37.021Z)
I recently wrote a AS3 to JS transcompiler that relies quite heavily on `__proto__`. The outputted JS works perfectly in both Chrome (SVG SUPPORT IS HORRIBLE, sorry, unrelated) and Firefox, and maybe even IE11 --I need to verify. Anyway, for projects like mine, it's very important that IE matches the same functionality as the other browsers --even if it's not up to spec. Also, if it wasn't for `__proto__`, I don't think I could have supported the entire AS3 spec... so, no hating on `__proto__` =)
I recently wrote a AS3 to JS transcompiler that relies quite heavily on __proto__. The outputted JS works perfectly in both Chrome (SVG SUPPORT IS HORRIBLE, sorry, unrelated) and Firefox, and maybe even IE11 --I need to verify. Anyway, for projects like mine, it's very important that IE matches the same functionality as the other browsers --even if it's not up to spec. Also, if it wasn't for __proto__, I don't think I could have supported the entire AS3 spec... so, no hating on __proto__ =) On Wed, Aug 21, 2013 at 7:44 PM, Brendan Eich <brendan at mozilla.com> wrote: > I implemented __proto__ ages ago and it caught on like a non-lethal social > disease, and that's how it works. The way it works ought to be how Annex B > specifies it. > > /be > > Suresh Jayabalan wrote: > >> >> According to sections B.3.1 <http://people.mozilla.org/%** >> 7Ejorendorff/es6-draft.html#**sec-B.3.1<http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-B.3.1>>#6.a >> and 16.1.1.1.2 <http://people.mozilla.org/%**7Ejorendorff/es6-draft.html# >> **sec-16.1.1.1.2<http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-16.1.1.1.2>>#3, >> implementations are expected to throw a TypeError exception if an object’s >> __proto__ is set with anything other than null or an object. Today the >> existing implementations (Chrome or Firefox) treat such assignments as a no >> op. >> >> Interestingly there are instances of web pages who assign /undefined/ to >> an objects __proto__ are found. For example yelp.com < >> http://www.yelp.com/biz/**potbelly-sandwich-shop-**seattle-4<http://www.yelp.com/biz/potbelly-sandwich-shop-seattle-4>> >> assigns undefined to __proto__ via a function call as follows. >> >> function(f) { return { __proto__:f } } >> >> Implementing as per the specification would break the zoom in/out >> functionality of Yelp as this function would throw a TypeError. Similarly a >> radio player on myspace.com <http://myspace.com/> would not work either. >> The fact that there are few instances we have seen in the wild would mean >> there could be more websites that could break. >> >> >> Is the v8/spidermonkey behavior of silently ignoring primitive >> assignments to __proto__ a bug? Or should the spec mandate silently >> ignoring assignments of primitives (or just undefined) to __proto__? >> >> - Suresh >> >> ______________________________**_________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >> > ______________________________**_________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130822/30aa7e93/attachment.html>