Version: (using KDE KDE 3.1.1) Installed from: RedHat RPMs OS: Linux <!--/* Testcase for: JavaScript for... in loses object order Browser: Konqueror 3.1-12 Red Hat (Using KDE 3.1-10 Red Hat) Submitted on 2002-08-19 at http://bugs.kde.org/wizard.cgi How to reproduce: - Open this file e.g. as index.html - Click on button "Test" Expected result: Object properties are listed in the same order as they are added in the constructor. Actual result: Object properties are mixed up. Comments: This is critical because there must be at least one reliable order that is not dependent on property names. If one wants a different order than one can always use Array.sort(). All other major JavaScript capable browsers, i.e. - Netscape 4 - Netscape 7 / Mozilla - IE4...6 on Windows - IE4...5 on Mac do preserve the order as exactly the same as the properties were added to objects. This is of great importance for object serialization into delimited strings that, in case of serialised collections, must always have the member count first otherwise they cannot be deserialized. I think it is generally not difficult to understand that for GENERIC serialisation and deserialisation, preserving the order of attributes within Object is absolutely essential. */--> <HTML> <HEAD> <TITLE>&qout;for..in..&qout; order lost</TITLE> <SCRIPT> // This is a constructor that creates a Model object from a string // of values delimited by "|" function Model(str){ var attrs = str.split("|"); var idx = 0; this.weight = attrs[idx++]; this.size = attrs[idx++]; this.color = attrs[idx++]; }// constr // This is a generic function that serializes an object into a string // of values delimited by "|" function serialize(obj){ var str = ""; for(var attr in obj){ str += obj[attr]; str += "|"; }// for return str; }// function function test(){ // Create a Model object from a string of values delimited by "|" var model = new Model("5kg|1.5m|blue|"); // Serialize this object var str = serialize(model, Model); // deserialize it var model = new Model(str); // Check if the object has kept all information including // the order of its properties, which is important for serialisation. if(model.weight == "5kg" && model.size == "1.5m" && model.color == "blue"){ alert("Test succeeded"); }// if else{ alert("Test failed\nmodel.weight = " + model.weight + "\nmodel.size = " + model.size + "\nmodel.color = " + model.color); }// else }// function </SCRIPT> </HEAD> <BODY> <FORM> <INPUT type = button value=Test onclick=test()> </FORM> </BODY> </HTML>
The ordering of properties is implementation dependent (see the standard). You shouldn't rely on it. If you want a fixed order do as you indicated above: use sort(). We might unify ordering of properties on day but it has to be done carefully in order not to decrease efficency.
Harri, Thanks for examining this issue. Unfortunately, the standard is painfully unhelpful in this particular case. Please let me use a very relevant analogy from the SQL database domain: If you are familiar with SQL database technology then you will recognise that in this domain, things are standardised and handled correctly: The SQL "SELECT * FROM MY_TABLE;" lists the contents of "MY_TABLE" in exactly the same column order as the fields were defined in the data definition language (DDL). Even in the DDL itself, when you add a field to an existing table layout, then it gets appended to the end of the layout, preserving the column order. As you know, the ECMA standard was only created AFTER thwo fairly solid JavaScript implementations existed for a significant period of browser history. Today on the web, for commercial applications, and I hate to say that for various other reasons, it is more practical to follow what Microsoft Internet Explorer and Netscape implement than what the standards are because these browsers cover more than 90% of all browsers on the web today. Because of this, it is not practical to penalise 90% of users with additional code only to accommodate nascent, incomplete technology. I am saying "incomplete" with some emphasis. As you know, there are quite a few JavaScript commands in browsers that are not part of the standard. However, all modern browsers today implement them because without these, browsers would not be very useful at all: window.open, document.write, window.setTimeout to name just a few. Last not least I am referring to commercial browser based applications. These applications have been released and they will generate thousands of web sites. They definitely use the natural for ... in order for critiacl purposes, in other words they do not function at all with a browser that does not implement it. I admire and to some extent share the enthusiasm of the KDE team for their product. And I am very enthusiastic to support their work wherever I can. That is why I am writing testcases early, to ensure that Konqueror gets on board. Please fix this bug as soon as your resources permit it.
*** This bug has been marked as a duplicate of 28474 ***