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>#6.a
and 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> 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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
