iteration order for Object

Brendan Eich brendan at mozilla.com
Thu Mar 10 19:18:35 PST 2011


On Mar 10, 2011, at 6:50 PM, Charles Kendrick wrote:

> Let's ignore, for the moment, the fact that the underlying implementation of Object and Array is very similar.

Not true in all modern optimizing VMs.


> Has a use case been identified where treating numeric properties differently from other properties is a desirable behavior?

Yes. Users occasionally create arrays empty and insert elements in reverse-index or other order. Then for-in discloses the insertion order if the array is deoptimized to be like an object, or else enumerates in index order if the array manages to be optimized.

Implementations are allowed to leak their optimization strategies via for-in, by explicit language in ES1-5.

So users complain, and almost always want for-in over an array to use index order.

If I'm reading you right, you don't mind us specifying arrays enumerating indexed "own" properties first and in index order.

But it gets worse: several notable JS libraries, including IIRC jQuery (the #1 library in popularity right now), use indexed properties on Object instances -- frequently. I'll try to dig up the references.

Those VMs that optimize indexed properties on Object to be (a) fast; (b, and therefore) enumerated in index order, do better on such code. VMs that optimize only for certain "dense-enough arrays" lose.

This creates pressure to follow the performance leader and treat indexed properties the same, in terms of enumeration, on all objects including arrays.


> Is there any programming language or library for any programming language where this behavior has been intentionally implemented as a collection class?

Not really relevant based on the pressures in the ecosystem at hand.


> In my limited experience both are "no".
> 
> Harmony is a clean break: seems like a great opportunity to implement the behavior for Object for..in iteration that is most useful.

Harmony is *not* a clean break. I don't know why you wrote that.

Harmony has some room to break compatibility, especially if the old forms are caught by early errors. I've spoken of one hand's worth of fingers to count these breaks (the "five fingers of fate"). The valuable and opposable thumb is for removing the global object from the scope chain. The index finger on my hand is paren-free relaxation of syntax combined with better for-in semantics. The middle finger may as well go for typeof null == "null" (which can't be caught by any early error in a practical implementation; testing and static analysis tools needed). And so on, but for only two more fingers (on my hand; others on TC39 may differ on particulars, and we all may have another hand behind our back with back-up candidates).

Harmony is *not* "anything goes", VB7 ("Visual Fred"), Cobol2000, or even Perl 6 vs. 5 (I'm not saying anything bad about Perl 6 here -- I like that it makes many and large changes based on lessons learned). Harmony must be mostly compatible with JS as it is today so that code can migrate forward.

/be



More information about the es-discuss mailing list