iteration order for Object

David Bruant bruant at
Sat Mar 12 11:58:17 PST 2011

Le 12/03/2011 19:41, Brendan Eich a écrit :
> On Mar 12, 2011, at 9:54 AM, David Bruant wrote:
>> The little "issue" I see in returning 1) index properties in ascending
>> order 2) all other properties in addition order is that there is a bit
>> of information lost in the process: overall property addition order
>> (index properties included).
> This is an issue in theory. Beware _a priori_ reasoning about usability issues.
I fully agree. I don't have myself a decent use case for that. My point
was just that if we standardize the order as in the strawman, we will
have lost forever the possibility to retrieve overall property order...

> In practice both users and (especially) implementors Do Not Want indexed properties enumerated in insertion order.
... but if especially implementors aren't willing to implement keeping
overall property order, then I understand that losing such a potential
can be considered at the spec level.

> The proof is the use of for-in over arrays, still common enough, also advised against (but that is like talking back to the tide).
>> What is the rational or use case behind having index properties at first
>> for objects and then the rest of properties?
> The "rationale" (such as it is) is that JS conflates lists and dicts in objects, but users mostly think about one or the other. When combining indexed and named properties, many users still want for-in to work sensibly and that means the list properties first in index order, the dict properties after in insertion order.
I understand the practice of users.
However, this practice has started to be forged at a time when the only
cross-browser way to iterate over own enumerable properties was
+ hasOwnProperty. This is a different story now (ES5) that we have all
object introspection methods (except in Opera according to Kangax
compat-table) and Array extras.

I also would like to remind that the enumeration order is used
in different places (for instance the Object.defineProperties methods,
which also means Object.create (second argument)). Losing the overall
order in loops also means loosing it for these methods. It also
means loosing it for proxies if I use Object.defineProperties(myProxy,
props), which will mean that even with proxies, I won't be able to
perfectly track property insertion order. I'll have some dependency on
the engine order.
So I was actually wrong when I said earlier in the thread that proxies
could be used to implement OrderedObject.

If users mostly think of JS objects as lists or dicts, would it make
sense to provide methods such as Object.numericProperties(o) and
Object.dictionaryProperties(o) (sorry, not very inspired for the name)?


More information about the es-discuss mailing list