iteration order for Object

David Bruant bruant at enseirb-matmeca.fr
Fri Mar 11 15:13:34 PST 2011


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


More information about the es-discuss mailing list