iteration order for Object

Charles Kendrick charles at isomorphic.com
Fri Mar 11 15:40:30 PST 2011


On 3/11/2011 3:13 PM, David Bruant wrote:
> Have you reported an issue to Microsoft Connect (or their bug reporting
> platform, I do not remember the exact name)?

I will report it the second that I can link to, say, an email from Brendan Eich replying to 2 
other heavies saying yeah, we're agreed ES4 & Harmony should specify in-order iteration as the 
default strategy.

(I am not impugning your waistline Brendan).

 > I still believe they won't do a
> change to the implementation even if the entire TC-39 committee was
> knocking at the IE team door in the next hour.

Great idea David, I'll catch a flight if you will ;)

> "These developers" didn't take a "calculated risk". They saw it worked
> with the implementations at the time and hoped it would be so in the
> future.

That is precisely the calculated risk they took.  Many were aware that technically, the spec 
left it undefined, but again, saw the feature as so obviously valuable that there would never 
be a reason to go against a behavior all browsers agreed on.

And again, I agree with them - I think the language should be standardized in exactly the way 
they assumed it would.

If you could go back in time and explain to those developers that we now have browsers that are 
10,000 times faster on hardware that's 10 times faster, but we're going to sacrifice in-order 
iteration in order to get a little bit more, I think they'd be stunned.

> But it requires some
> involvment anyway if you want your code to be robust over time. If you
> write code that is supposed to last one browser generation, you can rely
> on implementation details. If you want to write robust code, you have to
> make sure you understand the spec and are not relying on implementation
> specificities.

On robustness, just to set perspective, today I have the luxury of the extra speed and memory 
to make my own LinkedHashMap in JavaScript, as I showed - at the time some of these decisions 
were made, there was not enough "breathing room" to do this.  The applications would not have 
hit performance targets.

Think, in particular, of my second implementation in the context of the pre-IE7 garbage 
collector.  Sure, it rips through a million keys in a couple seconds on a modern Firefox 
browser, it also trebles the GC load relative to an Object: this is "game over" on older IE.

> If reminding this means bashing to you, then I am sorry, I am bashing
> developers. I may be wrong, but I think it's relevent to remind that it
> isn't the "spec fault" if developers didn't follow it while
> implementations did.

Not only do I agree it is not the spec's fault, I'm not interested in assigning blame at all, 
which was really my point.  Whoever we point to as "at fault", the language gets worse and a 
bunch of developers waste their time.



More information about the es-discuss mailing list