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_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
