Off the top of my head, I can't think of a case where the compare sub
would be needed unless the key was not well-ordered. Does anyone have
an example of a case where the key-extraction sub approach doesn't
reduce the problem to a Scalar comparison?
I can't find the P5 code I used for it right off, but I remember a case when I was playing around with various football (US) stats. I was ranking teams, and had something akin to:
@teams = sort {$b->{WinPct} <=> $a->{WinPct} ||
($a->{Conference} eq $b->{Conference}
?($b->{ConfWinPct} <=> $a->{ConfWinPct} ||
$b->{ConfWon} <=> $a->{ConfWon} ||
$a->{ConfLost} <=> $b->{ConfLost})
:($a->{Division} eq $b->{Division}
?($b->{DivWinPct} <=> $a->{DivWinPct} ||
$b->{DivWon} <=> $a->{DivWon} ||
$a->{DivLost} <=> $b->{DivLost})
:0
)
) ||
$b->{Won} <=> $a->{Won} ||
$a->{Lost} <=> $b->{Lost} ||
$b->{GamesPlayed} <=> $a->{GamesPlayed}
} @teams;
Creating a keycode for this situation is not a trivial task at all. So sorts do occur in the real world for which there is no straightforward way to generate a sortkey. Albeit considerably rare.
Also, I think there is utility in have a compare sub supported so that:
1) porting P5 code is easier. (a minor design rationale, but it exists)
2) people used to thinking in terms of compare subs (from C, P5, and points of the programming universe) can still think that way.
3) most importantly to me, so that There's More Than One Way to Do It.
-- Rod Adams
