iteration order for Object

[Charles Kendrick]

On 3/13/2011 2:07 PM, Brendan Eich wrote:
> On Mar 13, 2011, at 3:58 PM, Charles Kendrick wrote:
>
>> Brendan, Bradley and others - there's no need to search for a relatively uncommon use case for ordered maps indexed by keys - a far more common use case is enumerated data stored numerically, eg, marital status:
>>
>> {
>>    2: "Married",
>>    1: "Single",
>>    5: "Divorced"
>> }
>
> It's still a synthetic example, and real web sites/apps would be more compelling and helpful for forge consensus.

There's two separable and mutually reinforcing lines of argument here and the appropriate 
evidence is different for each:

1. backcompat issue

Here the primary evidence of developer pain is the Google Code issue with the record-setting 
127 stars and 116 comments

	http://code.google.com/p/v8/issues/detail?id=164

And these two duplicates:

75 stars, 22 comments:
	http://code.google.com/p/chromium/issues/detail?id=37404

32 stars, 17 comments:
	http://code.google.com/p/chromium/issues/detail?id=20144

I have not read everything in detail but there is at least one instance of someone pointing out 
that part of Facebook was broken by this in Dec 2010:

	http://code.google.com/p/v8/issues/detail?id=164#c81

If you slog through the rest of the comments on this and other issues closed as duplicates, you 
find a bunch of people complaining about broken apps/sites, saying that they are advising 
people not to use Chrome, etc, but, most are posting with generic email addresses and do not 
name the specific sites.

People are asking me on and off-list whether I can provide specific sites, but, I have no 
special access to know what these sites are.  I have around 10-12 definite reports from our own 
customers getting bitten by assuming order was preserved and thinking it was a bug in the 
framework, where we've had to give them the bad news.  These are all banks / insurers / defense 
apps, behind the firewall.

My intuition is that most of the posters in the Google Chrome issue are likewise 
behind-the-firewall business applications.  This is no way diminishes the importance of the 
applications that all these developers are posting about - if they are indeed mostly 
behind-the-firewall applications, then they deal with money and business processes and other 
high-value stuff.


2. usability / functional issue

By this I mean:

- the performance value of having Object be a native-speed order-preserving map implementation: 
4-6x faster than the fastest JavaScript implementation

- the loss of information going from an Object literal to a live Object if order is not preserved

- more verbose code / data definitions in various use cases

- the "gotcha" factor of Object appearing to preserve order but then dropping order for numeric 
keys, a reasonable behavior for Array but a surprise on Object

.. etc.

Here I don't think it makes sense to ask for an Alexa site or similar - we're talking about how 
common the use case is, not how popular the site is, and in this case I think the use case 
comes up most often in sites that would never appear in the Alexa 500, because they are 
business applications.

I have presented two main arguments about how common the use case is:

1. if you look through available collection classes in the class libraries of various 
languages, you will very often find an order-preserving map, but you won't find an 
implementation of a map that preserves order for string keys but not numeric.  To me, this 
strongly implies that the order-preserving map is a commonly desired behavior whereas a map 
that specifically drops order for numeric keys does not correspond to any common use case

2. order-preserving numerically-keyed maps are very common in any application that involves 
relational storage.  Since this crowd didn't receive this as an obvious statement in the way I 
expected, let me provide some further information:

If you consider enumerated fields (Order Status, Bug Status, Sex, Package Type, Employment 
Status, etc - they are ever-present) across all object-relational mapping systems across any 
programming language (Rails/Grails, Hibernate, Django, etc), storing such fields as numeric 
values is either the default or is an available option.

Likewise if you consider relations between objects (Account->Manager), typically an integer id 
is assigned to the record and stored in the related record.

For either type of information, when it is being delivered to the UI to be displayed, one very 
natural representation is a map from unique integer id to display value, eg Bug Status:

{
     2: "Fixed",
     1: "Verified",
     5: "Duplicate",
     ...
}

.. or search results (eg a combobox):

{
    43443: "Mark Mitchell",
    43113: "Mark Pierce",
    ...
}

This latter use case is basically what was broken on Facebook.

Hopefully this is enough to make it clear that the use case is very common.  Someone could, of 
course, go off scouring various web sites to try to find status fields stored as integers or 
related records keyed by numeric ids, but again, I would assert that this use case is most 
common in behind-the-firewall apps, so information about the Alexa 500 would be neither here 
nor there.

I hope that with the above context, it can be taken as obvious that "ordered data with numeric 
keys" is a common use case.