<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mar 14, 2011, at 9:42 AM, David Bruant wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div text="#000000" bgcolor="#ffffff">
    Le 14/03/2011 17:02, John Tamplin a écrit :
    <blockquote cite="mid:AANLkTi=GgMv9YdJSD4wn+be4R4dnKyKV+b-koptAk0bO@mail.gmail.com" type="cite">
      <div class="gmail_quote">On Mon, Mar 14, 2011 at 10:21 AM, Brendan
        Eich <span dir="ltr"><<a moz-do-not-send="true" href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>></span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <div class="im">Web developers find and exploit many de-facto
            standards. Enumeration order being insertion order for
            non-arrays at least, if not for all objects (arrays tend to
            be populated in index order), is old as the hills and web
            content depends on it, as far as I can tell. I'll do some
            experiments to try to get data on this.</div>
        </blockquote>
      </div>
      <div><br>
      </div>
      Aside from the JSON example of populating a dropdown list given
      (which I will agree is a real if contrived use case), there has
      been a lot of talk of "thousands of web developers" depending on
      preserving insertion order, but not one concrete example -- do you
      have one?<br>
    </blockquote>
    I gave one <span data-jsid="text"><a href="https://mail.mozilla.org/pipermail/es-discuss/2011-March/013036.html" rel="nofollow" target="_blank"><span>https://mail.mozilla.org/p</span><wbr><span class="word_break"></span><span>ipermail/es-discuss/2011-M</span><wbr><span class="word_break"></span>arch/013036.html</a><br>
      It is theorical (sorry, not concrete like "there is code using it
      right now"), but the point is that for objects (</span><span data-jsid="text">actual objects </span><span data-jsid="text">not
      arrays) used as "dictionaries", numbers could be used as
      "alphabetic keys". When the user writes objects as object literals
      in code, they might (not a single proof since it has never been
      the case) appreciate if the JS engine kept the order they have
      written the key in.<br>
      <br>
      The order the user provides the keys in is the only bit of
      information (I can think of) that the JS engine looses. But once
      again, if users would have appreciate this feature, they have been
      forced (by spec and implementations) to find other ways. So,
      unless we can reach all web devs to ask "have you ever been
      disappointed of the implementation for-in loop order?", you cannot
      really have facts on if they would use the feature. Apparently,
      for the case of non-numeric properties, they seem satisfied of the
      implementation which iterate them over<br>
      <br>
      For more concrete numerical results, let's wait for Brendan to do
      his experiments (or help him out if there is any way to do so?)<br>
      <br>
      <br>
    </span><span data-jsid="text">I think that in-memory objects
      (created as such) for-in enumeration and JSON.parse created
      objects are two different concerns. Of course, they should
      certainly be solved consistently, but they are different in my
      opinion. </span><br>
    <span data-jsid="text"><br>
      I am a bit worried about JSON. JSON as an interchange format is
      defined as unordered. "An object is an unordered collection of
      zero or more name/value pairs". If people expect JSON as an
      interchange format to be ordered, they are assuming something
      about the JSON parse method which isn't itself standardized
      either.<br></span></div></blockquote><div><div>If you inspect any JSON document that conforms to the RFC 4627 (for example,  {"y": 1 , "z":2, "x":3})  will see that each object clearly has some specific ordering of its name/value pairs. It must, it is inherent in such a textual representation. "y" is first, then "z", and finally "x". So the language in 4627 that says "An object is an unordered collection of zero or more name/value pairs" clearly can not be saying that the name/value pairs do not occur in some order.  It must mean something else.  Crock can probably tell us exactly what he intended those words to mean. Until he chimes in, I'll make an educated guess about the meaning.  It means that the order of  occurrence of key/value pairs should not be assigned any semantic meaning.  That, {"y": 1 , "z":2, "x":3} and {"x": 3 , "z":2, "1":1} and the 4 other possible permutations of these key/value pairs must all be considered semantically equivalent.</div><div><br></div><div>If you are defining a JSON-based schema for some application and that schema assigns semantic significance to key/value pair orderings you are doing sometime outside the bounds of RFC 4627.  You  may well get away with doing so, but there is no guarantee that when somebody tries to ready your JSON document using the FORTRAN  JSON library that the ordering information you thought was implicit will actually be visible to them.</div><div><br></div><div>BTW, there is a very straightforward way to encode a ordered set of key/value pairs using 4627 JSON:  ["y",1,"z",2,"x",3].  It's the exact same length as the "object" encoding.  If you want to easily decode it into an object (assume insertion ordering) you might encode it as ["ordered-n/v","y",1,"z",2,"x",3] and then process the document using JSON.parse with a reviver function like:</div><div><br></div><div>function reviver(k,v) {</div><div>   if (!Array.isArray(v)) return v;</div><div>   if (v[0]!=="ordered-n/v") return v;</div><div>   var o={};</div><div>   var len=v.length;</div><div>   for (var i=1;i<len;)  o[v[i++] ]= v[i++]; </div><div>   return o;</div><div>}</div></div><blockquote type="cite"><div text="#000000" bgcolor="#ffffff"><span data-jsid="text">
      <br>
      One conceptual issue I see with ordering in the ES spec
      JSON.parse-created objects is that the ECMA spec would explicitely
      say "we consider that objects are ordered and we decide an order
      for JSON.parse-created objects, (we decide of an order while there
      isn't in the JSON format)". Once again, it's conceptual. I would
      be in favor of adding an order, but it had to be said.<br>
      All of that said, it's a bit weird to say that an interchange
      format (so something with a beginning, an end and a direction) has
      some "unordered" part. The JSON grammar itself seem to contain an
      implicit order:<br>
      JSONMemberList :<br>
          JSONMember<br>
          JSONMemberList , JSONMember <br>
      <br>
      So I don't know. Does it really make sense to define JSON objects
      as an unordered collection in the interchange format (in-memory
      objects are a different story) or is it just an ECMAScript legacy?<br>
      <br></span></div></blockquote><div><br></div><div>In talking about JSON you need to be careful not to conflate the JSON interchange format defined by RFC 4627 with the serialization process required to convert that format to/from the object model of your favorite programming language.  These are two separate things. While, 4627 says name/value pairs are unordered, that doesn't prevent a JSON serialization library from specifying such ordering in its definition of the mapping between 4627 and language "objects" (or whatever language elements are used in the mapping).   ES5 does this for JSON.stringify when it says that the own properties are processed in the same order as produced by Object.keys.  It also specifies this for JSON.parse in step 3 when it says process the JSON document as if it was a ECMAScript Program.  This means the any property ordering that is implicit  in processing object ECMAScript object literals will also be applied to generated objects corresponding to JSONObjects.  (Where this falls short, is where ES5 for reasons already discussed doesn't require a specific enumeration order).</div><div><br></div><div>The reason the ES5 JSON spec talks about property ordering, even though 4627 does not, is because we would really like JSON.stringify when run on identical objects by two different ECMASScript implementations to produce exactly the same JSON output.  This isn't saying that the name/value pair ordering has meaning when 4627 says it doesn't.  it is just about making sure that ECMAScript implementations behave identically in as many ways as is possible. This is go for testing and overall interoperability among ECMAScript implementations.</div><div><br></div><div>Allen</div><div><br></div></div></body></html>