«

On 25 Mar 2006 20:54:48 -0800, "David McNerney" <> wrote:

>I duplicate your finding ... if those two print statements are
>commented out, both the nested sorts work correctly. So, it certainly
>does seem that the sort operator cannot always be relied upon when used
>with anonymous functions that contain anything but simple comparison.
>That's really fine, as far as I'm concerned, now that I know ... I can
>always declare a prototyped sort function in the future if I'm writing
>code that I expect to get called from within a sort. I don't, however,
>find any warnings about such code in the "sort" function documentation
>in the Camel book, my primary reference.
>
>There are any number of reasons why one might want to have what you
>refer to as "extra" code in a sort. This comes up when sorting objects.
>We have a large class library at our site, and one of the chief reasons
>that we use Perl, and not some other language like Java, C, or Visual
>Basic, is because it allows us to program at a high conceptual level,
>throwing around lists of objects with sort, grep and map. If you are
>sorting a list of objects, you might have code like this:
>
>my @sortedList = sort { $a->method() <=> $b->method() } @list;
>
A list of instantiated objects from which your calling method() to compare
encapsulated data? Cool... Just remember {} is a block, not an anonymous
sub.

In 'C', you can write structures (records or classes)
with common methods that know and act on common data, to be returned
to a pool collector, as in a sort or a find.

You should consider that any sort that can be done in method()
is absolutely misplaced when done in a general collecting scheme,
as you describe.

Has nothing to do with Perl sort. This is just common knowledge.
There is no example in 'C' you can give me that would justify this at all.

Sorry dude, the find is good, the premise is wrong.

robic0