Property Iteration in JSON serialization

Maciej Stachowiak mjs at apple.com
Wed Oct 14 22:47:21 PDT 2009


On Oct 14, 2009, at 8:34 PM, Brian Kardell wrote:

> Sorry... somehow Waldemar's comment got closed up in my Gmail
> conversation stack and I missed this comment...
>
> If Oliver and  Hallvord and Brendan are wrong on the idea that it is
> at least largely already a de facto standard for non-indexed
> properties then  I suppose it is a moot point...

Historically, the areas where JS engines in the major browsers have  
diverged on for..in enumeration order have been properties with index- 
like names, and properties on the prototype chain. I made a test case  
to study some of these differences.

Current JavaScriptCore and SpiderMonkey seem to get identical results  
on this, other browsers all have slight variations:

Here are some of the variations I found:

== Index properties on non-arrays ==
JSC/Safari - insertion order
SpiderMonkey/Firefox - insertion order
Futhark/Opera - insertion order
V8/Chrome - numeric sorted order
JScript/IE - insertion order

== Index properties on arrays ==
JSC/Safari - numeric sorted order
SpiderMonkey/Firefox - numeric sorted order
Futhark/Opera - insertion order
V8/Chrome - numeric sorted order
JScript/IE - insertion order

== Objects with enumerable properties in the prototype chain ==
JSC/Safari - own properties in insertion order, followed by prototype  
properties from most direct prototype to least direct (each prototypes  
properties in insertion ordr)
SpiderMonkey/Firefox - same
Futhark/Opera - same
V8/Chrome - properties are re-ordered, even own properties, but I  
don't understand the rule(*)
JScript/IE - prototype properties are reported before own properties;  
own properties are in order, but properties on every other prototype  
are reversed (I think?)


(*) - If you use constructor functions to make an object with  
properties named (x, y, z) added in that order, with a prototype that  
has properties (a, b, c), and in turn has a prototype with properties  
(q, r, s), JSC and SpiderMonkey report "x y z a b c q r s" but V8  
gives "x z y a c b q r s". I'm not sure what rule would give that  
output. I'm not even sure if this behavior is intentional or a bug.


The common behavior subset here is: for objects with no properties  
that look like array indices, and no enumerable prototype properties,  
for..in enumeration returns properties in insertion order. That  
particular behavior is a de facto standard and required for Web  
compatibility. A future standard should specify at least that much.

All the browsers besides Chrome also seem to report index-like  
properties on arrays in insertion order, and report own properties in  
insertion order even when there are enumerable prototype properties  
(though the prototype properties may be before or after). Perhaps  
somewhat self-servingly, I think the Safari/Firefox behavior is the  
most sensible overall, so if we ever fully standardize the enumeration  
order, that is what I would suggest.


Here's my test case if you want to try for yourself:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20091014/414c2f14/attachment.html>
-------------- next part --------------


Regards,
Macej



More information about the es-discuss mailing list