iteration order for Object
bradley.meck at gmail.com
Mon Mar 14 21:41:26 PDT 2011
---------- Forwarded message ----------
From: Bradley Meck <bradley.meck at gmail.com>
Date: Mon, Mar 14, 2011 at 11:41 PM
Subject: Re: iteration order for Object
To: charles.kendrick at isomorphic.com
Very nice examples. While I do think programming which requires this
is a bit odd it seems to be quite relied upon.
I would like to see the couple of comments peppered in by the
developer team in the chrome bugs about performance issues.
Otherwise it seems that the fact that we have what appears to be an
expectation of this with examples of breaking changes (though many
comments are missing these examples).
The fact that it has become an expectation for so many leads me to
agree that this should be standardized as long as there are no lasting
My concern for memory/performance affecting things outside of for...in
loops remains, but I am not close enough to engine internals to ensure
this to be a non-issue.
Overall, seems this needs standardization. Keep it with the most
backward compatible since it is a standard that has been reverse
engineered by implementation (and w3schools it seems).
On Mon, Mar 14, 2011 at 6:33 PM, Charles Kendrick
<charles at isomorphic.com> wrote:
> 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
> And these two duplicates:
> 75 stars, 22 comments:
> 32 stars, 17 comments:
> 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:
> 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
> - 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
> 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