Property Iteration in JSON serialization

Allen Wirfs-Brock Allen.Wirfs-Brock at
Thu Oct 15 10:23:54 PDT 2009

I'm not particularly defending IE's legacy enumeration order, we were initially on board with ES5 adopting the de facto order used by other browsers.  My recollection is that the decision to table defining a strict enumeration order for ES5 was made after we discovered that Opera for its optimized arrays did not follow the expected order and and many other messages in that thread.

We definitely should try to define a rational enumeration order.  It is a secondary issues as to whether we impose it as a potentially breaking change upon the existing for-in or introduce it via new syntax.  I think the second alterative is an approach we should at least consider not just in this situation but in all similar situations.  Sometimes it will make sense and other times it won't.


>-----Original Message-----
>From: Brendan Eich [mailto:brendan at]
>Sent: Wednesday, October 14, 2009 10:26 PM
>To: Allen Wirfs-Brock
>Cc: Mike Shaver; Waldemar Horwat; es-discuss
>Subject: Re: Property Iteration in JSON serialization
>On Oct 14, 2009, at 7:01 PM, Allen Wirfs-Brock wrote:
>> Similarly, rather than trying to fully specifying for-in enumeration
>> order (and invariably causing potentially breaking changes for some
>> implementations)
>I'm focusing on your parenthetical aside: we have precedent in Harmony
>(functions in blocks) for finding room to create a better standard
>where browsers do not agree, and therefore unless browser detection is
>going on, cross-platform JS on the web cannot depend on the
>intersection semantics (the empty set).
>I think we should investigate breaking changes. The IE JScript
>deviations document linked from
>contains some amazing details of IE"s for-in behavior:
>* Enumerate properties on immediate prototype in reverse order (w.r.t
>the order in which they were added)
>* Enumerate properties in-order on rest of the objects on the
>prototype chain
>* Enumerate properties in-order on present object.
>Reverse insertion order on the immediate prototype properties, not
>something other engines do.
>Array element enumeration details are lacking, but again if the
>observation that array elements are almost always created in index
>order, then insertion order == index order. The exceptions may or may
>not work as expected on insertion-order-only implementations. Firefox
>3+ uses index order. We're not receiving bug reports.
>There's room to find a better common semantics here, it seems to me.

More information about the es-discuss mailing list