<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Sep 29, 2011, at 7:34 PM, David Bruant wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Le 29/09/2011 20:10, Brendan Eich a écrit :<br><blockquote type="cite">On Sep 29, 2011, at 6:54 PM, Geoffrey Sneddon wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">On 28/09/11 00:06, Waldemar Horwat wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Should we standardize __proto__ in Annex B?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">MarkM + a few others:  Yes<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Waldemar, Doug:  No<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Unless we have a definite plan that no ES.Next impl will support __proto__, then by all means don't standardize it.<br></blockquote></blockquote><blockquote type="cite">It is a standard (de-facto)<br></blockquote>What is a de facto standard exactly? The fact that '__proto__' allows to<br>get and set the prototype? This basic definition stands, but I have<br>heard of bugs: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=690027">https://bugzilla.mozilla.org/show_bug.cgi?id=690027</a><br><br>Firefox 7 recently added a '__proto__' property to Object.prototype<br>(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=690031">https://bugzilla.mozilla.org/show_bug.cgi?id=690031</a>). Would it be part<br>of the non-mandatory spec?<br></div></blockquote><div><br></div>We did not recently <i>add</i> anything to Object.prototype. We had a very old (13 years?) __proto__ property that appeared to be "own" by the obvious tests, but which was on Object.prototype (you could tell with less obvious tests such as the one in the first bug you filed, 690027). Here's a session in a 2008-era (Firefox 3) js shell I keep around:</div><div><br></div><div><div>js> Object.prototype.hasOwnProperty('__proto__')          </div><div>true</div><div>js> Object.prototype.hasOwnProperty.call({}, '__proto__')</div><div>true</div><div><br></div></div><div>In the latest SpiderMonkey,</div><div><br></div><div><div>js> Object.prototype.hasOwnProperty('__proto__')</div><div>true</div><div>js> Object.prototype.hasOwnProperty.call({}, '__proto__')</div><div>false</div><div><br></div></div><div>We got rid of the old non-standard hack by which __proto__ appeared to be "own". That seems worse to me, but (see below) I'm not losing sleep over it right now.</div><div><br></div><div>BTW, we do properly parse JSON that defines a key named "__proto__", and IIRC V8 does not. I suspect (haven't checked) that V8 and other engines that say __proto__ is not "in" and in particular not "own" for any object, but which implement it, do so as Rhino does, with special casing in [[Get]] and [[Set]] equivalents.</div><div><br></div><div>I'm not sure what we would spec if we did make an optional Annex B spec, at this point. But we could argue about it if that seems worthwhile (it doesn't right now to me).</div><div><br></div><div><br></div><div><blockquote type="cite"><div>Making __proto__ part of the spec sounds like an incitation to authors<br>to use it.</div></blockquote><div><br></div>No, the Annex B stuff does not "incite" anyone.</div><div><br></div><div>The problem is people already use __proto__. Turning a blind eye in the spec doesn't stop them. Apparently IE is feeling heat to implement. See Thomas Fuch's Zepto library, popular on mobile. Nothing in any spec could incite what has already happened.</div><div><br></div><div><br><blockquote type="cite"><div> I agree that implementors should agree for interoperability<br>purposes, but I'm not sure the official ECMAScript standard is the right<br>place to do so since it is intended for authors as well.<br></div></blockquote></div><br><div>Annex B is already full of such stuff.</div><div><br></div><div>We were only ever talking about Annex B. That was made clear in this thread. That must matter, given the precedent already there, ignoring __proto__.</div><div><br></div><div>You do raise the point that if the intersection semantics are too thin, or we can't agree on standardizing only [[Get]] and [[Set]] hardcoding, then some implementations will have to adjust. That may happen anyway.</div><div><br></div><div>/be</div></body></html>