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]