On Thu, 12 Feb 2004 15.40, Joe Gottman wrote:
> This is unrelated to the problem you mentioned, but there is another
> annoying problem with sort as it is currently defined. If you have an
> @array and you want to replace it with the sorted version, you have to type
> @array = sort @array;
>
> Besides being long-winded, this causes Perl to make an unnecessary copy of
> the array. It would be nice calling if sort (or reverse, or other similar
> functions) in void context resulted in in-place modification of the array
> that was input.
I just know that this has come up before . . . I don't remember whether it was
consensus[1] or just my wishful thinking that this would make code like:
sub foo
{
my $listref = shift;
# other stuff...
# return sorted list.
sort @$listref;
}
morally ambiguous[2], because that "sort" is being called in whatever context
the function call was in, which could be miles away.
I'd suggest that an in-place sort have a marginally different name, but the
rubyometer is already redlined as it is.
(Even more OT: I dislike the scoping rules for named sorting subroutines in
Perl 5. It means you can't do questionable things like this:
# A common function used all over the place.
sub onewayorother { $direction * ($a <=> $b) }
# much later ...
my $direction = -1;
my @arr = sort onewayorother (5,7,9);
The more I look at that, the more I think it's a stupid example, but I have a
vivid memory of being upset about it several years ago, when I wasn't a very
good programmer. This is looking less like a whinge and more like a
confession. Move along, nothing more to see here.)
[1] If, by "consensus", you mean "Larry Said No."
[2] Not semantically ambiguous, because it isn't.
--
Debbie Pickett
http://www.csse.monash.edu.au/~debbiep
[EMAIL PROTECTED]
