A couple of quick notes: - I just updated http://wiki.ecmascript.org/doku.php?id=strawman:enumeration to cite this thread by linking to the head message from Charles. Good feedback here, we on TC39 are processing it and we'll talk about it at the meeting in two weeks.
- Dave Herman just wrote up http://wiki.ecmascript.org/doku.php?id=strawman:dicts which he proposed to me last week in reaction to the same old chestnut of an issue that you raise here: the pollution of objects-as-dictionaries by prototype-delegated property names, and depending on the implementation a few magic built-ins. Comments welcome on dicts, I'm sure. /be On Mar 13, 2011, at 8:50 AM, John Tamplin wrote: > On Sun, Mar 13, 2011 at 5:57 AM, Claus Reinke <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
