Le 14/06/2013 09:55, Andreas Rossberg a écrit :
On 14 June 2013 09:50, David Bruant <bruan...@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.
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
