<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">I think my message has been taken the
      wrong way, so I should clarify it:<br>
      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.<br>
      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.<br>
      "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"<br>
      That really is all what I meant, no more, no less.<br>
      <br>
      Also... hmm... I wouldn't be spending that much time on standards
      mailing-list, this one included, if I didn't believe in
      standardization ;-)<br>
      <br>
      <br>
      Detailed answer below.<br>
      <br>
      Le 31/07/2012 14:07, Allen Wirfs-Brock a écrit :<br>
    </div>
    <blockquote
      cite="mid:46EEC993-6CAF-4F77-B12A-DABA34305F6D@wirfs-brock.com"
      type="cite">
      <pre wrap="">The following was WRT [[Put]]/[[CanPut]] semantic issues:  

On Jul 28, 2012, at 6:02 AM, David Bruant wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">Le 28/07/2012 14:37, Herby Vojčík a écrit :
</pre>
        <blockquote type="cite">
          <pre wrap="">...
:-/ But that is how it is, no?
</pre>
        </blockquote>
        <pre wrap="">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.

David
</pre>
      </blockquote>
      <pre wrap="">
I have to disagree with David's sentiments here. Situations like this is exactly why we have standardized specifications.</pre>
    </blockquote>
    I agree.<br>
    But I'd like to add that situations like this also show the
    limitations of standardized specifications (more on that at the end)<br>
    <br>
    <blockquote
      cite="mid:46EEC993-6CAF-4F77-B12A-DABA34305F6D@wirfs-brock.com"
      type="cite">
      <pre wrap="">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.</pre>
    </blockquote>
    I do the opposite analysis: major implementations recognize the
    importance of interoperability due to market constraints, thus the
    need for a standard.<br>
    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.<br>
    <br>
    <blockquote
      cite="mid:46EEC993-6CAF-4F77-B12A-DABA34305F6D@wirfs-brock.com"
      type="cite">
      <pre wrap="">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.
</pre>
    </blockquote>
    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.<br>
    <br>
    <br>
    Brendan Eich wrote:<br>
    <blockquote type="cite">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)</blockquote>
    it's unfortunate this information wasn't on the meeting notes, but
    I'm glad to hear it :-)<br>
    <br>
    <blockquote type="cite">and a stinky statement of anti-realpolitik.
      In the current market, if we don't hew to a consensus standard,
      anything goes.<br>
      <br>
      Not that everyone would make breaking changes, or any changes,
      just that from the presence of a bug or long-standing deviation
      (in this case copied from JavaScriptCore, which has since fixed
      the deviation!) does <b class="moz-txt-star"><span
          class="moz-txt-tag">*</span>not<span class="moz-txt-tag">*</span></b>
      mean that "what the spec says doesn't really matter."
      <br>
    </blockquote>
    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.<br>
    <br>
    <blockquote type="cite">
      Or were you snarking at V8?
      <br>
    </blockquote>
    I was not.<br>
    <br>
    <br>
    More on the limitations of standardization I talked about above.<br>
    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 [1] 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.<br>
    <br>
    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.<br>
    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 version not-so-standard.<br>
    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?<br>
    <br>
    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.<br>
    <br>
    I hope I have made my position more clear.<br>
    <br>
    David<br>
    <br>
    [1]
<a class="moz-txt-link-freetext" href="http://blogs.msdn.com/b/ie/archive/2010/07/16/how-ie9-platform-preview-feedback-changed-the-javascript-standard.aspx">http://blogs.msdn.com/b/ie/archive/2010/07/16/how-ie9-platform-preview-feedback-changed-the-javascript-standard.aspx</a><br>
  </body>
</html>