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]

Reply via email to