Array#sort(prop)

Herby Vojčík herby at mailbox.sk
Mon Apr 2 00:46:26 PDT 2012



Mark S. Miller wrote:
> Quoting from <http://es5.github.com/#x15.4.4.11>, the requirements on
> the comparefn are:
>
>         A function /comparefn/ is a consistent comparison function for a
>         set of values /S/ if all of the requirements below are met for
>         all values /a/, /b/, and /c/ (possibly the same value) in the
>         set /S/: The notation /a/ <_CF /b/ means /comparefn/(/a/,/b/)
>         < 0; /a/ =_CF /b/ means /comparefn/(/a/,/b/) = 0 (of either
>         sign); and/a/ >_CF /b/ means /comparefn/(/a/,/b/) > 0.
>
>         Calling /comparefn/(/a/,/b/) always returns the same value
>         /v/ when given a specific pair of values /a/and /b/ as its two
>         arguments. Furthermore, Type <http://es5.github.com/#Type>(/v/)
>         is Number, and /v/ is not NaN. Note that this implies that
>         exactly one of /a/ <_CF /b/, /a/ =_CF /b/, and /a/ >_CF /b/ will
>         be true for a given pair of /a/ and /b/.
>
>         Calling /comparefn/(/a/,/b/) does not modify the *this* object.
>
>         /a/ =_CF /a/ (reflexivity)
>
>         If /a/ =_CF /b/, then /b/ =_CF /a/ (symmetry)
>
>         If /a/ =_CF /b/ and /b/ =_CF /c/, then /a/ =_CF
>         /c/ (transitivity of =_CF )
>
>         If /a/ <_CF /b/ and /b/ <_CF /c/, then /a/ <_CF
>         /c/ (transitivity of <_CF )
>
>         If /a/ >_CF /b/ and /b/ >_CF /c/, then /a/ >_CF
>         /c/ (transitivity of >_CF )
>
>         *NOTE*
>
>           The above conditions are necessary and sufficient to ensure
>         that /comparefn/ divides the set/S/ into equivalence classes and
>         that these equivalence classes are totally ordered.
>
>
> If sort is called with a comparefn which violates this constraint,
> according to normative text
>
>         If /comparefn/ is not *undefined* and is not a consistent
>         comparison function for the elements of this array
>         <http://es5.github.com/#array-element> (see below), the
>         behaviour of |*sort*| is implementation-defined.
>
>
> a conforming implementation may kill the user, lose memory safety, or
> launch the nukes.
>
 > ...
>
> Let's kill "implementation-defined" rather than our users.

IIRC there was already this topic on the list some time ago.

BTW, is it so hard just to change the spec to something like:

If /comparefn/ is not *undefined* and is not a consistent
comparison function for the elements of this array
<http://es5.github.com/#array-element> (see below), the
behaviour of |*sort*| can be any of:

- throwing an exception raised in comparator function by throw 
statement, leaving array in one of its permutations*
- changing array to one of its permutations* and returning the array
- infinite loop
- stack overflow exception / out of memory exception, leaving array in 
one of its permutations*
- throwing TypeError, leaving array in one of its permutations*

at the discretion of the implementor.

* not changing the array at all also counts as "leaving the array in of 
its permutations"

> --
>      Cheers,
>      --MarkM

Herby


More information about the es-discuss mailing list