iteration order for Object

Brendan Eich brendan at mozilla.com
Sun Mar 13 13:58:05 PDT 2011


On Mar 13, 2011, at 4:57 AM, Claus Reinke 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).
> ..
>> 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.

That is one point of view. Unfortunately, the horses have left the barn and are on different continents, or planets, now.

It's likely some developers take the point of view that non-array, or even any-object, enumeration should enumerate indexed properties in index order, the rest in insertion order. While other developers, and I can believe with the weight of history on their side *more* developers, expect insertion order as a rule at least for non-arrays.

I wrote recently in a private reply on this topic:

"... for-in is too "DWIM" and fuzzy, and often developers don't know exactly what they mean. Determining "most used intersection semantics" (which might be one mode; there could be other important but less-used modes) is hard.

That's why in paren-free I proposed not making subtle runtime changes to the meaning of for (x in o) in Harmony, rather banning that syntax. It won't pay to inflict too much runtime semantic innovation on the same old syntax, especially where the old syntax and semantics are misunderstood and even variable across implementations.

Instead, the idea is to use standard iterators to say what you mean, as in Python. The default for x in o (paren-free) still should do enumeration on objects, so we need to pin down enumeration. As David noted, it is used internally in ES5 in a number of places, even though underspecified horribly."


> A spec workaround would be to stop converting numeric keys to
> Strings, ie, 1 and '1' would be different keys.

This is how JS as I implemented it in 1995 at Netscape, and on until some point in 1997 or 1998 (in any event, before the creation of cvs.mozilla.org from Netscape's internal CVS repo), worked: indexes that fit in a certain tagged int representation were reflected as number-type (typeof sense) keys.

Obviously this was too implementation-dependent, but also better for efficiency and often enough, for users who wanted to avoid string-type indexes.

Again, I think trying to change for-in's runtime semantics too much, without breaking its syntax is a mistake. Even indexed-first-in-index-order may be a bridge too far, as Charles and others argue and as the heated discussion in the V8 issue indicate.

With paren-free for-in, users can select from standard iterators to visit keys, values, items (key-value pairs), indexes (of numeric type), etc.

The question of the default meaning of for x in o {...} in a paren-free Harmony remains, and as noted above (David Bruant's point), the spec uses enumeration internally. So we nee to pin something down.

My inclination right now, frankly, is to avoid compatibility hassles and runtime-testing migration taxes by codifying what most engines across the current in-the-field and latest-release (and bleeding-edge) browsers do, and not make indexed-first-in-index-order universal for all objects.

Who needs the migration hassle? If paren-free syntax becomes Harmonious, there will be plenty of sugar to make up for default-enumeration being the same old salt.

I do agree with your point that "proper coding" means prefixing string keys to avoid indexes being enumerated in other than insertion order, but again: reality with JS is messy; programmers don't all code "properly"; many eyes will glaze over at your "LinkedHashMap" Java talk. ;-)

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110313/bcbd04e3/attachment.html>


More information about the es-discuss mailing list