iteration order for Object

Claus Reinke claus.reinke at
Sun Mar 13 01:57:45 PST 2011

>>>> 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).
> Music album in which one title is a number. I lose the opportunity to
> store the album as a dictionary indexed on titles and sorted the order I
> have inserted the keys in. I would be forced to use an array. This is
> where the notion of dictionary finds some limitation.

Please note that this use case highlights the highjacking of numeric
Strings as indices, not the lack of overall property addition order
including indices.

A spec workaround would be to stop converting numeric keys to
Strings, ie, 1 and '1' would be different keys. Then number keys
could behave as Array indices, while String keys would behave
as other properties. This would avoid the gaps in the String keys
highlighted by your use case, but you would still not get a full
record of insertion order. Doing that might make insertion
ordering slightly more palatable, though.

Btw, if you really need to organize your music now, and don't
feel like using a proper LinkedHashMap, you could prefix all
your keys with ':' or something similarly non-numeric;-) That 
would avoid the auto-conversion/index ordering, at the price
of messing up your access code.


More information about the es-discuss mailing list