Set iterators

David Bruant bruant.d at gmail.com
Tue Feb 14 00:47:30 PST 2012


Le 14/02/2012 07:22, Erik Arvidsson a écrit :
> On Mon, Feb 13, 2012 at 21:25, Jason Orendorff
> <jason.orendorff at gmail.com>  wrote:
>> Unless TC39 specifies otherwise, the enumeration order of Map and Set
>> will be arbitrary, it will certainly be inconsistent across browsers,
>> and it will most likely even include a random component per Map/Set
>> object.
>>
>> It is very hard to see how any code could depend on a particular
>> implementation's enumeration order if it is randomized.
> I think we should be careful not to specify the iteration order and we
> should make sure that the first two implementations intentionally do
> not agree on the ordering.
>
> This is our one time chance to get this right and we don't want to
> paint us into another corner with Map/Set iteration order.
It cannot be a "one time chance". This property (implementations not 
agreeing) would need to be followed, because if at some point, some 
implementations do agree, we'll be back to where we started and people 
will start relying on enumeration order.

Moreover, maybe the 2 first implementations will disagree, but maybe 
some implementations will agree (either in all cases or in some 
observable cases that people will use in their code).

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.

Determinism makes JavaScript code more interoperable.

David


More information about the es-discuss mailing list