 |  |
The return operator immediately returns a value from a subroutine:
my @names = qw/ fred barney betty dino wilma pebbles bamm-bamm /;
my $result = &which_element_is("dino", @names);
sub which_element_is {
my($what, @list) = @_;
foreach (0..$#list) { # indices of @list's elements
if ($what eq $list[$_]) {
return $_; # return early once found
}
}
-1; # element not found (return is optional here)
}This subroutine is being used to find the index of "dino" in the array @names. First, the my declaration names the parameters: there's $what, which is what we're searching for, and @list, a list of values to search within. That's a copy of the array @names, in this case. The foreach loop steps through the indices of @list (the first index is 0, and the last one is $#list, as we saw in Chapter 3, "Lists and Arrays ").
Each time through the foreach loop, we check to see whether the string in $what is equal[118] to the element from @list at the current index. If it's equal, we return that index at once. This is the most common use of the keyword return in Perl -- to return a value immediately, without executing the rest of the subroutine.
[118]You noticed that we used the string equality test, eq, instead of the numeric equality test, ==, didn't you?
But what if we never found that element? In that case, the author of this subroutine has chosen to return -1 as a "value not found" code. It would be more Perlish, perhaps, to return undef in that case, but this programmer used -1. Saying return -1 on that last line would be correct, but the word return isn't really needed.
Some programmers like to use return every time there's a return value, as a means of documenting that it is a return value. For example, you might use return when the return value is not the last line of the subroutine, such as in the subroutine &list_from_fred_to_barney, earlier in this chapter. It's not really needed, but it doesn't hurt anything. However, many Perl programmers believe it's just an extra seven characters of typing. So you'll need to be able to read code written by both kinds of programmers.
If return is used with no expression, that will return an empty value -- undef in a scalar context, or an empty list in a list context. return ( ) does the same, in case you want to be explicit.
As promised, now we'll tell you the rule for when a subroutine call can omit the ampersand. If the compiler sees the subroutine definition before invocation, or if Perl can tell from the syntax that it's a subroutine call, the subroutine can be called without an ampersand, just like a builtin function. (But there's a catch hidden in that rule, as we'll see in a moment.)
This means that if Perl can see that it's a subroutine call without the ampersand, from the syntax alone, that's generally fine. That is, if you've got the parameter list in parentheses, it's got to be a function[119] call:
[119]In this case, the function is the subroutine &shuffle. But it may be a built-in function, as we'll see in a moment.
my @cards = shuffle(@deck_of_cards); # No & necessary on &shuffle
Or if Perl's internal compiler has already seen the subroutine definition, that's generally okay, too; in that case, you can even omit the parentheses around the argument list:
sub division {
$_[0] / $_[1]; # Divide first param by second
}
my $quotient = division 355, 113; # Uses &divisionThis works because of the rule that parentheses may always be omitted, except when doing so would change the meaning of the code.
But don't put that subroutine declaration after the invocation, or the compiler won't know what the attempted invocation of division is all about. The compiler has to see the definition before the invocation in order to use the subroutine call as if it were a builtin.
That's not the catch, though. The catch is this: if the subroutine has the same name as a Perl builtin, you must use the ampersand to call it. With an ampersand, you're sure to call the subroutine; without it, you can get the subroutine only if there's no builtin with the same name:
sub chomp {
print "Munch, munch!";
}
&chomp; # That ampersand is not optional!Without the ampersand, we'd be calling the builtin chomp, even though we've defined the subroutine &chomp. So, the real rule to use is this one: until you know the names of all of Perl's builtin functions, always use the ampersand on function calls. That means that you will use it for your first hundred programs or so. But when you see someone else has omitted the ampersand in their own code, it's not necessarily a mistake; perhaps they simply know that Perl has no builtin with that name.[120]
[120]Then again, maybe it is a mistake; you can search the perlfunc and perlop manpages for that name, though, to see whether it's the same as a builtin. And Perl will usually be able to warn you about this, when you have warnings turned on.
When programmers plan to call their subroutines as if they were calling Perl's builtins, often when writing modules, they often use prototypes to tell Perl about the parameters to expect. Making modules is an advanced topic, though; when you're ready for that, see Perl's documentation (in particular, the perlmod and perlsub documents) for more information about subroutine prototypes and making modules.
|  | |
| 4.10. The use strict Pragma |  | 4.12. Exercises |
Copyright © 2002 O'Reilly & Associates. All rights reserved.