iteration order for Object

Claus Reinke claus.reinke at talk21.com
Sat Mar 12 02:04:25 PST 2011


>>> I believe it is very very important that the ECMAScript standard
>>> specify that when a new Object is created, for..in iteration traverses
>>> properties in the order they are added, regardless of whether the
>>> properties are numeric or not.
>>
>> Some users might prefer 'in the order of keys'. That is predictable,
>> and allows for efficient implementation (both sparse and dense).
>
> Are you suggesting changing the enumeration order which is currently
> implemented as "iteration order matches insertion order" under the
> careful set of conditions Allen enumerated earlier in this thread?  (e.g.
> no enumerable props on prototype).

Normally, I don't like to object to features that group A finds useful
and group B is happy to implement, just because I wouldn't use them
myself. Let me explain why I jumped in anyway:

Current situation: the standard not only doesn't specify any ordering,
it explicitly specifies that no ordering is to be relied on. So, I don't
rely on any ordering, and those who do are mostly happy because
most implementers happen to support an ordering.

Unfortunately, that isn't the happy situation it seems to be - the first
implementers may have broken rank already, others have said that
they just haven't got round to investigating the potential gains.

Proposed situation: the standard specifies the current insertion order.
As has been pointed out, current practice has several exceptions, so
one would have to (a) specify a simple insertion order and force
implementers to go against the direction they like to go or (b) specify
the current least common denominator and add to the complexity of
the specification.

>From the discussion here, I'm not even convinced that everyone
asking for an insertion ordering is thinking about the same thing.
If all participants were happy with

    http://wiki.ecmascript.org/doku.php?id=strawman:enumeration

    (is it just me, or does this page have a character problem with
    tabs in the table?)

then we wouldn't have this thread, right?

As a user, I still don't have an immediate problem if I ignore that
ordering, but as a toolsmith, I now have to support this ordering;
when reasoning about someone else's code, I have to think about
this ordering and whether the author relied on it; and since
supporting the spec will become another little bit more
complicated, there will be fewer tools attempting to do so, a
shortcoming which will bite me as a user, too.

So, ultimately, I find it acceptable that the ordering is not specified,
but I doubt that this is a stable situation for coders or implementers.
If the ordering is to be specified, then yes, I would prefer a simple
ordering that doesn't impede implementers, instead of an ordering
that looks simple ("just as written"), but becomes complicated
when written down in full, with all "ifs" and "buts".

'In the order of keys' might be such a simple ordering, and has the
additional advantage that 'order' could be an overridable operation,
just like a sort parameter: alphabetical for string keys in Object,
numerical for number keys in array, by insertion record for some
new type of object.

> If so - the thought of this makes me pretty nervous.  There is
> undoubtedly significant amounts of code in the wild on the web
> which depend on the current enumeration order, and changing
> this would increase the size of the harmony-uptake tax (code
> audits and refactors).

Specification complexity makes me even more nervous than
code that relies on others to clean up behind it.

It might not be immediately obvious, given that Ecmascript's
spec is so complicated already, but once the spec gets under
a certain barrier of complication (both in what it specifies and
how it specifies it), tools get much easier to implement. Some
automatic transformations become provably correct, and even
if that goal is still far off, I would expect tools that highlight
problematic code automatically (leaving confirmation/fix to
coders) to be viable, iff the objects that rely on insertion
ordering are known (by comments/annotation/subclassing).

In theory, I would hope any code that goes against the spec to
be accompanied by assertions/regression tests that fail in useful
ways when browsers change order. Then one could write tools
that flag enumerations that might be the cause of trouble. In
practice, that is probably too much to hope.

In practice, one might want to start flagging enumerations
that rely on ordering: whenever you find such, wrap the object
in an identity function, just so that the code is easy to find when
or if it needs fixing:

    for (var i in obj) { .. } ==> for (var i in inorder(obj)) { .. }

    // NOTE: caller relies on insertion ordering of obj keys!
    //             (see test #42 and documentation)
    function inorder (obj) { return obj; }

It isn't so much a tax, and not for Harmony, but more of a debt,
right now, taken in the hope of a future spec waiving the payback.

That debt might be manageable. Whereas the tax of further
complicating the spec or the language described by it would not.

Claus

 



More information about the es-discuss mailing list