bruant.d at gmail.com
Tue Feb 14 03:02:23 PST 2012
Le 14/02/2012 11:23, Andreas Rossberg a écrit :
> On 14 February 2012 09:47, David Bruant<bruant.d at 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 :-)
More information about the es-discuss