iteration order for Object

John Tamplin jat at
Sun Mar 13 06:50:18 PDT 2011

On Sun, Mar 13, 2011 at 5:57 AM, Claus Reinke <claus.reinke at>wrote:

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

If you are trying to use an object to store arbitrary values as a hash map,
you already have to do something like this -- otherwise you run into
problems with trying to store various values like "prototype", "__proto__",
"watch", etc. (and the list of dangerous values varies by browser).

If you "know" your data can't conflict, then of course you can use it
directly, but then you are likely to have subtle bugs when your assumption
turns out to be wrong.

John A. Tamplin
Software Engineer (GWT), Google
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list