Property Iteration in JSON serialization

Maciej Stachowiak mjs at apple.com
Thu Oct 15 11:40:35 PDT 2009


On Oct 15, 2009, at 10:23 AM, Allen Wirfs-Brock wrote:

> 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 https://mail.mozilla.org/pipermail/es5-discuss/2008-May/001286.html 
>  and https://mail.mozilla.org/pipermail/es5-discuss/2008-June/001304.html 
>  and many other messages in that thread.

I think my email on this thread summarized the current areas of  
divergent behavior (complete with test cases). It basically amounts to:

- Different behavior for index-like properties (either insertion order  
or numeric order, in some implementations different between arrays and  
non-arrays). Firefox and Safari seem to agree, no other two browsers  
agree with each other.
- Different behavior for prototype properties in IE.
- Properties created by a constructor are enumerated in arbitrary  
order, in Chrome only (I assume this is a bug, so I'm going to ignore  
it in the discussion below).

> 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.

Even if we don't fully specify the order for for..in, there is a  
significant intersection of behavior that Web content depends on,  
namely that own properties which don't look like indices get  
enumerated in insertion order. Even if we don't fully specify the  
order, we should at least specify that much in a future ES spec.

I also think removing the differences in handling of index properties  
and prototype properties is unlikely to be a breaking change for  
anyone, so I believe we could fully specify the order in a future ES  
spec.

Regards,
Maciej

>
> Allen
>
>
>> -----Original Message-----
>> From: Brendan Eich [mailto:brendan at mozilla.com]
>> 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
>>
>> http://wiki.ecmascript.org/doku.php?id=es3.1:es3.x_working_docs&s=jscrip
>> t+deviations
>>
>> 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.
>>
>> /be
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list