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
>> 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.
More information about the es-discuss