Allow me to disagree.
I mean, obviously, it's not "breaking specifications", as there does NOT seem to be available specifications (because the documentation does NOT seem to mention how "sort" orders elements), but still, it furiously looks like an unwanted behaviour, or, at the very least, a caveat worth mentioning.
I'm guessing that adding a single paragraph to the documentation, telling that a positive result orders in the following way, a negative result orders in the other way, and a null result keeps the same order, and that it is STRONGLY RECOMMENDED to use the binary comparison operator for this, to avoid potential problems, would do the trick.
Because, I'll be blunt, but I had no recollection whatsoever of having previously worked with the "comparison" operator. And if it's not explained why one should use it, then... why not use something more familiar, and doing the same thing ? I mean, this is Perl, and "There is more than one way to do it", right ?
| [reply] |
Perl often defers to C, or underlying platform, when it comes to specifications. (Sort of a hand-wave.) This seems to be the case here, as well. Read the page on qsort and compare to sort. Here's the pertinent quote:
If SUBNAME is specified, it gives the name of a subroutine that returns an integer less than, equal to, or greater than 0, depending on how the elements of the list are to be ordered.
So the behaviour is documented, and there is a discrepency in perl. You could try to fix the perl sources to address this issue. (But be sure then to run all tests. I've no clue why it's coded that way; there might be a reason.)
| [reply]
[d/l] |
