__proto__ in Annex B
Le 29/09/2011 20:10, Brendan Eich a écrit :
On Sep 29, 2011, at 6:54 PM, Geoffrey Sneddon wrote:
On 28/09/11 00:06, Waldemar Horwat wrote:
Should we standardize proto in Annex B? MarkM + a few others: Yes Waldemar, Doug: No Unless we have a definite plan that no ES.Next impl will support proto, then by all means don't standardize it. It is a standard (de-facto)
What is a de facto standard exactly? The fact that 'proto' allows to get and set the prototype? This basic definition stands, but I have heard of bugs: bugzilla.mozilla.org/show_bug.cgi?id=690027
Firefox 7 recently added a 'proto' property to Object.prototype (bugzilla.mozilla.org/show_bug.cgi?id=690031). Would it be part of the non-mandatory spec?
Making proto part of the spec sounds like an incitation to authors to use it. I agree that implementors should agree for interoperability purposes, but I'm not sure the official ECMAScript standard is the right place to do so since it is intended for authors as well.
On Sep 29, 2011, at 7:34 PM, David Bruant wrote:
Le 29/09/2011 20:10, Brendan Eich a écrit :
On Sep 29, 2011, at 6:54 PM, Geoffrey Sneddon wrote:
On 28/09/11 00:06, Waldemar Horwat wrote:
Should we standardize proto in Annex B? MarkM + a few others: Yes Waldemar, Doug: No Unless we have a definite plan that no ES.Next impl will support proto, then by all means don't standardize it. It is a standard (de-facto) What is a de facto standard exactly? The fact that 'proto' allows to get and set the prototype? This basic definition stands, but I have heard of bugs: bugzilla.mozilla.org/show_bug.cgi?id=690027
Firefox 7 recently added a 'proto' property to Object.prototype (bugzilla.mozilla.org/show_bug.cgi?id=690031). Would it be part of the non-mandatory spec?
We did not recently add 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:
js> Object.prototype.hasOwnProperty('proto')
true js> Object.prototype.hasOwnProperty.call({}, 'proto')
true
In the latest SpiderMonkey,
js> Object.prototype.hasOwnProperty('proto')
true js> Object.prototype.hasOwnProperty.call({}, 'proto')
false
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.
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.
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).
Making proto part of the spec sounds like an incitation to authors to use it.
No, the Annex B stuff does not "incite" anyone.
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.
I agree that implementors should agree for interoperability purposes, but I'm not sure the official ECMAScript standard is the right place to do so since it is intended for authors as well.
Annex B is already full of such stuff.
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.
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.
On Thu, Sep 29, 2011 at 11:46 AM, Brendan Eich <brendan at mozilla.com> wrote:
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.
Yes, this is v8 bug code.google.com/p/v8/issues/detail?id=621. It
is tested by test262 test "S15.12.2_A1" and (currently) test 32 at < es-lab.googlecode.com/svn/trunk/src/ses/explicit.html>, which also
repairs it safely on all platforms on which it is broken. By my testing, it works fine on FF and Opera. And I expect it works fine on IE10, since it doesn't special case "proto", but I'm on a Mac right now.
Strangely, this also works fine on the released Safari 5.0.6 but not the latest WebKit Nightly r96318. For WebKit, it seems this is a new bug.
On 29/09/11 19:10, Brendan Eich wrote:
Well, de-jure standard is what I meant (even a non-mandatory one).
Indeed. I'm not expecting browsers to change behaviour blindingly based upon the spec, but from what I can see the number of instances of people writing proto breaks almost nothing, so it may be entirely possible to make it non-writable.
But, in general, in any case like this, I'd say the spec should follow implementations, not the other way around. If browsers are still going to support it, we should spec it.