Le 11/03/2011 23:07, Charles Kendrick a écrit : > On 3/11/2011 1:33 PM, David Bruant wrote: >> Le 11/03/2011 21:49, Charles Kendrick a écrit : >>> Yes Allen, hence the urgency. If IE9 final ships that way, the "goose >>> is cooked": >> Let's face it right now: IE9 will ship that way. They're on RC phase, >> it's completely irrealistic to consider they would change object >> implementation. >> From the spec point of view, there is no urgency since Harmony won't >> ship for couple of years I think. > > I disagree - if there is a clear consensus that ECMAScript will > standardize on a particular iteration order, there's a strong chance > IE9 will update to reflect this (so, on reflection, I should not have > said the goose is cooked). > > They are aggressively embracing standards across the board now, after all. Have you reported an issue to Microsoft Connect (or their bug reporting platform, I do not remember the exact name)? For the record, IE9 will be officially released on March 14th. 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.
>>> 1. we will have a new de facto standard iteration order for Object >>> that does not match any known use case - it is purely an >>> implementation detail leaking through >> As said by someone else, the iteration order has never been >> standardized. It was dangerous from the developers to base their code on >> an implementation detail even though this one was at some point >> consistent accross browsers. Standards aren't only for implementors. > > Your perspective is common in a group like this - very spec and > standard focused. Isn't it fun to bash those developers? Everyone's > doing it.. I hope you realize it's irrelevant though? I can't talk for everyone in the list, but I came to that list as a web developer. I am still a student, I am still learning. I wouldn't define myself as "very spec and standard focused". As I said in a previous e-mail, I would have certainly made the mistake myself. My intention is not to bash anyone. I read and try to understand standards because I understand that a standard is a contract between the implementor and the programmer. In an ideal world, implementors respect the spec (and they have quite well for ECMAScript) and programmers can understand the language from the spec. In the real world, a spec is a difficult document to read. This is why people write documentation with tutorials and exampels. Have you checked that your favorite documentation to make sure it warned on the fact that for..in loops enumerate in an implementation-independent manner and that it could cause bug? If it's a wiki, have you edited it? If web developers don't want to take the time to understand the language, they're exposing themselves to bugs in the longer-run. > These developers took a calculated risk at a time when standards were > so vague and partial that they had to take similar risks everywhere. The DOM is a mess. DOM-related standards and actual implementations were a huge mismatch. Different story for ECMAScript. As far as I know, ECMAScript 3 has been followed in an interoperable manner in web browsers, IE6 included. And I quote ECMAScript 2, released in August 1998 (http://www.ecma-international.org/publications/standards/Ecma-262-arch.htm) about the for-in loop: "The mechanics of enumerating the properties (...) is implementation dependent." Almost thirteen years that it's specified as implementation-dependent. "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. I'm doing this too when in a rush. It doesn't prevent me from checking when the rush stops. 13 years leaves some decent time to check. Checking MDN: * https://developer.mozilla.org/en/JavaScript/Reference/Statements/for...in#Description : "A for...in loop iterates over the properties of an object in an arbitrary order (see the delete operator for more on why one cannot depend on the seeming orderliness of iteration, at least in a cross-browser setting) ..." * delete page (https://developer.mozilla.org/en/JavaScript/Reference/Operators/Special_Operators/delete_Operator#Cross-browser_issues): "Although ECMAScript makes iteration order of objects implementation-dependent, it may appear that all major browsers support an iteration order based on the earliest added property coming first (at least for properties not on the prototype). However, in the case of Internet Explorer, when one uses delete on a property, some confusing behavior results, preventing other browsers from using simple objects like object literals as ordered associative arrays. In Explorer, while the property value is indeed set to undefined, if one later adds back a property with the same name, the property will be iterated in its old position--not at the end of the iteration sequence as one might expect after having deleted the property and then added it back. So if you want to simulate an ordered associative array in a cross-browser environment, you are forced to either use two separate arrays (one for the keys and the other for the values), or build an array of single-property objects, etc." This part seem to have been added on January 12th 2010, so it seems to regard IE6-8. Back to the idea of a standard being a contract between implementors and developers, implementors have respected their part of the contract quite well with regard to ECMAScript (once again, different story with the DOM). Developers should try to worry about the "contract" too. ECMAScript is a programming language. It has been first designed in order to help non-programmers (semi-column insertion, silent failure, scripting language...) to write programs. 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. 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. David _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
