Le 14/02/2012 11:23, Andreas Rossberg a écrit :
On 14 February 2012 09:47, David Bruant<bruan...@gmail.com> wrote:
For instance, what if Firefox and Chrome disagree, but iPhone safari and
Android Webkit agree?
Also, some products (Node.js (V8), MongoDB (SpiderMonkey), etc.) rely only
on one JS engine, so JS code written for these could rely on the particular
order of the given implementation. If it is the case, it will force these
implementations to keep their order for backward-compat sake.
Worst case, 2 non-compatible implementations are forced to keep their
different order for some products built on top of them each relying on the
particular order, making it impossible later to specify a given order.
To be sure, this is assuming that iteration order is fixed for a given
implementation. If order is not specified, then I don't see why that
should be required either.
It is not required, but it's what experience tells us from the for-in
loop. Spec said it was impl-specific, but implementations mostly
implemented iteration order as insertion order.
Regardless of requirement, if an implementation gets to a point where in
cases observed by people looks deterministic, then they may assume it
is, start relying on it and force the implementation to keep this order.
Requiring fixed iteration order and same order for all implementations
saves us from these issues.
I.e., a completely randomized order (per
iteration) should be valid, too.
And I see potential reasons why order might differ for separate
iterations over the same collection.
I'm interested in hearing more :-)
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
