Array#sort() implementations not interoperable
bruant.d at gmail.com
Fri Jun 14 01:17:58 PDT 2013
Le 14/06/2013 09:55, Andreas Rossberg a écrit :
> On 14 June 2013 09:50, David Bruant <bruant.d at gmail.com> wrote:
>> And this particular behavior might be standardizable without a loss (even
>> with a gain), because:
>> 1) a sort algorithm only needs all the array values once at least once
>> (serie of [[Get]]s) and should probably avoiding touching the array again
>> since getter or get traps may be costly and return inconsistent values (so
>> [[Get]] the values at most once)
>> 2) the sorting algorithms is on the values, not on the array (though with
>> membranes, if the comparator function touches more than the object identity,
>> it can be observable, but that's not the problem of the sort algorithm)
>> 3) No sort algorithm requires to rearrange more elements than the number
>> there is in the array.
> Given that you can still observe implementation-dependent invocations
> of the comparison function I don't see what is really gained by this.
The current non-determinism of sort allows: "an implementation-dependent
sequence of calls to the [[Get]] , [[Put]], and [[Delete]] internal
methods of obj and to SortCompare"
I'm suggesting to make the [[Get]], [[Put]] and [[Delete]] sequence less
implementation-dependent which means at least to bound them to the
maximum of what is needed. That's a gain especially in the presence of
getter/setter and proxies (where an impl-dependent sequence can lead to
more calls than necessary).
> Trying to make a complex operation like sorting fully deterministic is
> a fruitless endeavour in an impure language.
I didn't suggest to make it fully deterministic. Only to make a bit more
predictable the [[Get]]/[[Put]]/[[Delete]] sequence. The sequence of
SortCompare calls can remain as implementation-dependent as they want.
More information about the es-discuss