iteration order for Object
Charles Kendrick
charles at isomorphic.com
Mon Mar 14 16:33:34 PDT 2011
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.
More information about the es-discuss
mailing list