JavaScript Iteration Order

The blogosphere has been flooded with Google Chrome-related posts for the past week or so, especially in the niches catering to web developers, browser developers and JavaScript enthusiasts. I haven’t tried it out yet, but I don’t see why that should keep me from joining the fracas ;-)

The Chrome team’s vision is refreshing. Their technology is intriguing. Their future? Uncertain. However, these topics have been explored in such depth that any effort at original contributions in these areas, at this time, are almost certainly useless.

I did, however, have to smile when I read John Resig’s post on JavaScript in Chrome. In it, he highlights a number of JavaScript issues in this new browser, the third one being for loop ordering:

Currently all major browsers loop over the properties of an object in the order in which they were defined. Chrome does this as well, except for a couple cases… If an object contains a value which is not a primitive… then its properties will be enumerated in a different order from which they were defined.

This is an interesting bug due to one fact: This behavior is explicitly left undefined by the ECMAScript specification… However, specification is quite different from implementation. All modern implementations of ECMAScript iterate through object properties in the order in which they were defined. Because of this the Chrome team has deemed this to be a bug and will be fixing it.

The reason I find this amusing is that the Rhino codebase suffered from the exact same problem, only recently adhering to the de facto standard which in this area subsumes the de jure ECMAScript standard.

We had a number of HtmlUnit users complain about this lapse, and even now the fix is not available in any official Rhino releases — hence HtmlUnit’s Rhino fork.

It appears implementers are doomed to repeat this mistake until such time as this unofficial convention is given official sanction. The recent outbreak of common sense, pragmatism and brotherly love on the ECMAScript committee is cause for optimism.

As John Resig mentions in his post on ECMAScript 3.1, much of the committee’s recent work has focused on standardization of such conventions:

Probably the most important development within all this [ECMAScript Harmony news] is the codification of existing de facto standards. For example, the concept of JavaScript getters and setters (implemented by Mozilla, Apple, and Opera) are going to be quickly fast-tracked into the specification (in the case of getters and setters they already have been). Seeing real-world code quickly make a bee-line for standardization is truly heartwarming. We’ll probably see more of this for topics like ‘let’ and ‘expression closures’ – but which will arrive post-ECMAScript 3.1 (since they require new syntax).

So will definition-order property iteration make it into ECMAScript 3.1? One can only hope, for the sake of the V9, V10 and V11 development teams…

UPDATE: The current (September 1st, 2008) ECMAScript 3.1 spec contains the following comment regarding the text in question:

We considered specifying the enumeration order but there were too many issues with existing implementations that optimize the representation of arrays.


1 Comment

  1. karl said,

    August 13, 2009 at 3:08 am

    Very frustrating, thanks for clearing this up for me.


Get every new post delivered to your Inbox.

%d bloggers like this: