The proposed ordering for [[OwnPropertyKeys]] is the same as the current
for..in ordering in the latest versions of most browsers.
As Allen pointed out, this group has basically declined to specify for..in
ordering, and specifying an order for [[OwnPropertyKeys]] *technically*
leaves for..in order unspecified.
However, I believe that specifying an order for [[OwnPropertyKeys]]
*effectively* specifies the order of for..in iteration, for the practical
reason that browser implementers are really unlikely to provide two
possible orderings. It would require a bunch of extra data structures and
indices to offer good performance for multiple possible orderings.
Given this, I would suggest that if ECMA is going to specify an order for
[[OwnPropertyKeys]], it's time to go ahead and specify for..in iteration
order too.
Regardless of what the ordering is (what I prefer, or what Allen proposed),
if for..in ordering is *technically* unspecified but implementation
concerns basically require a particular order, that's the worst of all
outcomes: every browser is consistent and the matter is really settled, but
no one can rely on it.
However, for the record, I continue to think that special treatment of
numeric keys is a really bad design for property order for Objects (for
Arrays, it's fine). To summarize the arguments that seemed to play best
with members of this group:
1. special treatment of Array indices is surprising
If we're spec'ing that order is preserved for String properties, people
will continue to routinely use Objects as ordered maps [1].
This leads to the gotcha that some properties fall out of order, just
because they happen to be parsable as numbers, even if you explicitly
quoted the property name in your code. Consider:
var extensions = {
"0110":"Marketing",
"1225":"Development",
"0301":"Support"
};
This way of specifying phone extensions in order would work, except that
"Development" is inexplicably placed first because 1225 is an array index.
To be crystal clear: I'm not raising this as a backwards compatibility
issue (which some people seem to take as a cue to argue uselessly about who
is to blame..).
What I'm saying is that this is a "gotcha" being permanently enshrined in
the spec, that will bite people from time to time for as long as ECMAScript
is in use.
2. treating array index keys specially loses information
If order was preserved, an Object would be a very convenient structure for
storing the list of available options in order, as a map from stored
integer values to user-visible Strings:
var availableOptions = {
"9" : "Fixed"
"3" : "Won't Fix"
"5" : "Invalid"
};
Not being able to to do this is a loss of expressiveness for a *very*
common use case in database-oriented apps.
3. treating array indices as special does not match any known use case
No one has identified any application in which it would be desirable for
*Object* (again *not* Array) to have this particular quirk of property
ordering. It's purely an optimization detail leaking through.
[1] if anyone doubts that using Objects as ordered maps has been a
long-standing practice, just look at the record-setting 178 stars and long
comment thread on just one of the several bugs filed against Chrome for not
preserving order for integer keys:
https://code.google.com/p/v8/issues/detail?id=164
There's no reason to assume this practice will go away, especially since
savvy developers will now know that it's safe to assume order preservation
for String keys.
On Sat, Apr 19, 2014 at 12:17 PM, Brendan Eich <bren...@mozilla.org> wrote:
> Did you check against http://wiki.ecmascript.org/doku.php?id=strawman:
> enumeration which links off to this es-discuss thread:
>
> https://mail.mozilla.org/pipermail/es-discuss/2011-March/012965.html
>
> Sounds good, just asking for a look-back at the big thread and strawman to
> see if there are any missing subtleties others have pointed out in the past.
>
> /be
>
> Allen Wirfs-Brock wrote:
>
>> The ordering I propose is:
>> 1) All array index property keys, in ascending array index numeric order.
>> Followed by:
>> 2) All other string property keys, in property creation order. Followed
>> by:
>> 3) All symbol property keys, in property creation order
>>
>> Does anybody see any reason why we shouldn't specify (this) property
>> ordering?
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
