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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

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.