The documentation for LzReplicationManager#setComparator says:
* @param Function|String comparator: "ascending" or "descending"
for the
* appropriate dictionary sort, or a function to be used for
comparison that
* takes two arguments and returns 1 if the second argument should
follow the
* first, -1 if the first argument should follow the second, and 0
if the two
* arguments are equivalent
Okay, that's upside down from "normal" comparator functions, and
described in an especially circuitous way, just to keep me guessing.
Compare to the ECMA documentation for Array#sort which takes a
comparator function:
it should be a
function that accepts
two arguments x and y and returns a negative value if x < y, zero if
x = y, or a positive value if x > y.
I guess that explains why our implementation of "descending" is upside-
down from what I would expect:
function descDict ( a , b ){
if ( a.toLowerCase() > b.toLowerCase() ) return 1;
}
But, this function does not even obey the contract of a comparator
function! It returns either undefined or 1, not -1, 0, or 1.
Apparently this all works because we use our own hand-written
LzReplicationManager#mergesort, which only looks for the comparator
returning 1 or not. (And sorts in the opposite order from what I
would have expected.)
As I said in my earlier message: Does anyone know why we use our own
sort rather than the built-in Array#sort, which must surely be
faster? Is it because our comparator functions are backwards? Or
something else?
