NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
What will the end user see... (Score:1)
But why, it seems so pointless and a waste of CPU.
The answer is that from the OUTSIDE of the method call, the user doesn't necesarily know that it went through sort, or whether the data for the list came pre-sorted.
All they know is that they called a method and it returned a list. And the general assumption will be that scalar of it returns the quantity.
As for wasting CPU with the sort, who's to know that the sort doesn't create some form of
Re: (Score:1)
I’d say to skip sorting and return the number of elements efficiently. It would help the common case (
return sortin scalar context), and I’ve never written a sort block with side effects, can’t imagine what it’d be useful for, or have seen any such thing in anyone else’s code, whether on PerlMonks or the CPAN.I believe that unlike being undefined in scalar context, not sorting in scalar context is a kind of surprise that’s not very surprising, and if anyone really need
Oh no, side effects. (Score:2)
The defense to that is that side effects in sort are so rare that this is hardly a real world gotcha. Does anyone put side effects in their sort?
Re: (Score:1)
I wouldn’t worry about that.
First: we’re not trading gotchas:
$ perl -le'@x = sort {++$_; $a cmp $b} qw(foo bar baz); print $_ || "nada"'3
$ perl -le'$x = sort {++$_; $a cmp $b} qw(foo bar baz); print $_ || "nada"'
nada
This is already part of the “
sortin scalar context is undefined” gotcha.Second – and as I’ve said –, I’ve never wanted to use side effects in a
sortblock, I can’t imagine a good reason that needs it, and I’ve never seen aMeta note (Score:1)
I think you wanted to link http://use.perl.org/~schwern/journal/28577 [perl.org], not http://use.perl.org/~schwern/journal/ [perl.org].
Re:Meta note (Score:2)
__ (Score:1)
That's easy. With map and grep, you can't determine the size of the output list purely from the size of the input list. So, having map and grep return the sizes of their output lists (if the functions were run in list context) in scalar context make sense.
For sort to ignore its first (optional) argument, and have it act as a counting function doesn't make any sense. We already have a function that does this: the list assignment in scalar context.
Re: (Score:1)
It’s not that having
sortact as a counting function is useful. It’s that no credible argument can be made against it, and that no suggestions for any sensible alternative have been forthcoming in 10 years.return should do what I mean (Score:1)
a scalar. I couldn't understand why I wasn't
getting a reference to the array.
Re:return should do what I mean (Score:2)
That's actually the default behavior in Perl 6. You're jumping the gun :)
Jumping the gun Re:return should do what I mean (Score:1)
use feature :scalar_sort;" should allow "return sort {f} @A" to morph to "return [sort {f} @A]" in scalar context ?undefstill seems safestBill
# I had a sig when sigs were cool
use Sig;