iteration order for Object

Kevin Smith khs4473 at
Mon Mar 14 09:52:03 PDT 2011

I don't know about insertion order being important, but certainly it's
natural to want to express order with object literals (or equivalently,
JSON).  If we can't rely on enumeration order matching key ordering in the
literal, then the programmer has to express that ordering twice:  once
implicitly in the literal and once explicitly through whatever data
structure is chosen to represent that order.  There would seem to be some
(seemingly) unnecessary repetition going on there, from the programmer's
point of view.

On Mon, Mar 14, 2011 at 12:42 PM, David Bruant <bruant at>wrote:

>  Le 14/03/2011 17:02, John Tamplin a écrit :
> On Mon, Mar 14, 2011 at 10:21 AM, Brendan Eich <brendan at>wrote:
>> 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.
>  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?
> I gave one
> arch/013036.html
> It is theorical (sorry, not concrete like "there is code using it right
> now"), but the point is that for objects (actual objects 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.
> 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
> 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?)
> 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.
> 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.
> 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.
> 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:
> JSONMemberList :
>     JSONMember
>     JSONMemberList , JSONMember
> 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?
> David
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list