July 25, 2012 - TC39 Meeting Notes
bruant.d at gmail.com
Tue Jul 31 17:05:08 PDT 2012
I think my message has been taken the wrong way, so I should clarify it:
From a practical point of view, if 2 implementations differ on one
aspect of the language, it means that there is no content relying on
either of the 2 implementations for that aspect of the language, whether
they follow the spec or even both diverge differently from it.
Not having content relying on this aspect also opens the door to
changing the behavior if it's considered as a mistake. This applies to
the "override mistake", but every single test262 test failure on any
major implementation could also be seen as an instance of such an open
door to change the spec.
"what the spec says doesn't really matter" seems very negative taken out
of context, but within the context i said it, it meant something
positive along the lines of "there is room to improve the specification
on this part if necessary"
That really is all what I meant, no more, no less.
Also... hmm... I wouldn't be spending that much time on standards
mailing-list, this one included, if I didn't believe in standardization ;-)
Detailed answer below.
Le 31/07/2012 14:07, Allen Wirfs-Brock a écrit :
> The following was WRT [[Put]]/[[CanPut]] semantic issues:
> On Jul 28, 2012, at 6:02 AM, David Bruant wrote:
>> Le 28/07/2012 14:37, Herby Vojčík a écrit :
>>> :-/ But that is how it is, no?
>> That's what the spec says, but V8 has implemented something else (and I
>> haven't seen an intention to change this behavior), so what the spec
>> says doesn't really matter.
> I have to disagree with David's sentiments here. Situations like this is exactly why we have standardized specifications.
But I'd like to add that situations like this also show the limitations
of standardized specifications (more on that at the end)
> Different implementors can easily have differing interpretations about the edge case semantics of loosely described features. An important role of standards is to align implementations on a common semantics. Sure, an implementation can refuse to go along with the specification but that is quite rare, at least for ECMAScript where all major implementations seem to recognize the importance of interoperability.
I do the opposite analysis: major implementations recognize the
importance of interoperability due to market constraints, thus the need
for a standard.
Although almost no one talks about it these days, I think the most
important part of HTML5 was specifying what's already in some browsers,
making clear for the other browsers what to implement to be interoperable.
> In particular, I haven't seen any indication that V8, as a matter of policy, is refusing to ever correct this deviations.
> It's true that what the spec. says makes no difference to the browser bits that have already been shipped. It does make a difference over the long term. Single implementation deviations from the specification usually get fixed eventually. Conformance to the specs. is a motivator for implementors.
> We really shouldn't foster the meme that specs don't really matter. they matter a lot.
I hope I have clarified that I don't buy into the meme that specs don't
matter. I was only reacting to the fact the 2 major implementations
differ on one aspect of the spec, making in practice what the spec says
on that aspect useless.
Brendan Eich wrote:
> I missed this until Allen's reply called it out. It is both false
> (Google people at the TC39 meeting last week said it's a V8 bug that
> is going to be fixed)
it's unfortunate this information wasn't on the meeting notes, but I'm
glad to hear it :-)
> and a stinky statement of anti-realpolitik. In the current market, if
> we don't hew to a consensus standard, anything goes.
> Not that everyone would make breaking changes, or any changes, just
> that from the presence of a bug or long-standing deviation (in this
> does *not* mean that "what the spec says doesn't really matter."
I guess I should have added "here" at the end of my sentence to clarify
that I didn't mean that the whole spec doesn't matter, but only the part
about [[CanPut]]/[[Put]] that's not interoperably implemented.
> Or were you snarking at V8?
I was not.
More on the limitations of standardization I talked about above.
As I said, I understand the importance of a standard and I don't buy in
the idea they are useless. I also don't buy in the idea that standards
should be seen written-in-stone documents. We all know that specs
sometimes have mistakes in them and when it's necessary and possible,
they are fixed. It was discovered that ES5 had such a mistake  and
the standard has been consequently fixed. This change additionally to
implementations following make that what was said in the spec about
Object.prototype.toString before the fix did not matter (only the part
that was controversial). The fact that it did not matter was actually a
pre-requisite to being able to change it, because if it did matter, if
content relied on that part, the specification couldn't have been changed.
Also, I think there is something much more important than the
specification document itself which is the standardization process.
What's happening here (es-discuss and TC39 meetings) is more important
than writing a document. What's happening is that major stakeholders
come to an agreement. This is far more important than the standard
itself. The standard is just the codification of this agreement. For
things that have been implemented, it's just a reminder. And for
anything that hasn't been implemented yet, it's just an hopeful promise.
If it happened that some feature made it to an ECMAScript 6 standard,
but not in any implementation, would it matter? If implementations
diverge, the standard will have to be fixed anyway, making the previous
Actually that's a good question: is it planned to have in
ES.next-the-standard features that wouldn't be implemented at the time
the standard is released?
I often read on Twitter or blogposts people saying things like "TC39,
hurry up!" or complaining that the next version of the standard takes
too much time to be released. I think it's misguided. When the standard
as a document is released doesn't matter. When implementations are ready
is. And as we have seen with WeakMaps, it doesn't take a standard, it
takes an implementor agreement.
I hope I have made my position more clear.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss