iteration order for Object

Charles Kendrick charles at isomorphic.com
Sun Mar 13 13:58:13 PDT 2011


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"
}

Likewise maps from numeric primary key values to display values for the records.

So this use case comes up just about every time JavaScript is manipulating data coming from a SQL database - extremely common.

On Mar 12, 2011, at 3:47 PM, Brendan Eich <brendan at mozilla.com> wrote:
 
>> 3. Object has a useful behavior (similar to Java LinkedHashMap) instead of a surprising behavior (treating indices specially)
> 
> The argument from Java leaves many cold.

Argument from Java??? You wound me, sir!  I would never argue from the viewpoint of such a verbose language and far prefer your JavaScript.

To rephrase my argument so that it does not appear to be rooted in Java: take any library of collection classes from any language: C, C++, Python, perl, Ruby, Forth, whatever: do you ever find a collection class that is written to preserve order of string keys but not numeric keys?

I don't know of one.

So we're looking at standardizing a behavior for Object that no one has ever felt the need to implement as a reusable component.

I would argue this means we're standardizing a very rare use case.


>> This is aside from the performance 
> 
> Perhaps these people should rewrite their code,

To be fair we're talking about a pretty tiny rewrite, in many cases a one-line change.  I made the change to JQuery is about 5 lines, with no apparent functional difference in a medium-size app.

If someone can point out a benchmark involving JQuery where Chrome appears to win due to dense Arrays, I can try it out, verify a performance difference if it's real, and submit the patch.  After all it applies to current Firefox regardless of what is decided here.

> but now we are in a perverse game: Chrome and possibly other browsers (I haven't tested IE9) optimize their code better than other browsers.

Glad to see the phrase "perverse game" here.  I feel that the right behavior for the language is in danger of being sacrificed for an advantage in synthetic benchmarks that don't reflect the real-world use cases we should really be optimizing for.



More information about the es-discuss mailing list