On Sun, Mar 13, 2011 at 5:57 AM, Claus Reinke <claus.rei...@talk21.com>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
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
