Property Iteration in JSON serialization

Brendan Eich brendan at
Wed Oct 14 22:31:09 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...

Waldemar did not cite non-indexed property counter-examples to  
insertion order, and insertion order is the rule among browsers.  
However, I did just posted a reference to:

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

from the first pdf link in

to highlight Pratap's revelation that IE JScript (at least some  
versions) use reverse-insertion order for the immediate prototype's  
enumerable properties.

But so what? Enumerable prototype properties are rare and they are  
considered bad practice. IE alone behaves in this exceptional manner  
for the direct prototype's properties. As far as I know, all other  
implementations use insertion order for non-indexed properties.

We are not going to standardize this anomaly, and cross-browser JS  
can't count on it. So we should standardize something saner, possibly  
insertion order for named properties, index order for indexed.


> On Wed, Oct 14, 2009 at 4:24 PM, Waldemar Horwat  
> <waldemar at> wrote:
>> Brian Kardell wrote:
>>> It sounds to me like there is wide agreement in the sense that at
>>> least the basics rules and only disagreement on the fringes...
>>> Otherwise no one on this list in particular would be suggesting that
>>> there is anything remotely like a "de facto" implementation... It
>>> seems that at least those basic rules are required just to function
>>> with the existing expectations everywhere.
>>> It also seems that those expectations aren't likely to change any  
>>> time
>>> soon for the "default" for-each iteration order whether more robust
>>> and interesting proposals are adopted...
>>> So can't that much be formalized and documented regardless of  
>>> whether
>>> or not new introductions are made to over-ride "other" predictable
>>> iterators to be used in for-each (or perhaps even some new mechanism
>>> entirely)? The simple fact that conforming to the spec would  
>>> currently
>>> create a non-workable solution seems to argue that at least the "de
>>> facto" parts should be included...
>>> No?
>> No.  As I wrote, there is no de-facto implementation order because  
>> the
>> implementations do not agree on the order in general, and what you  
>> call
>> "fringes" such as numbers do matter.  Trying to force, say,  
>> insertion order
>> would likely break compatibility.
>>   Waldemar
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list