 |  |
That subroutine called larger_of_fred_or_barney would be much more useful if it didn't force us to use the global variables $fred and $barney. That's because, if we wanted to get the larger value from $wilma and $betty, we currently have to copy those into $fred and $barney before we can use larger_of_fred_or_barney. And if we had something useful in those variables, we'd have to first copy those to other variables, say $save_fred and $save_barney. And then, when we're done with the subroutine, we'd have to copy those back to $fred and $barney again.
Luckily, Perl has subroutine arguments. To pass an argument list to the subroutine, simply place the list expression, in parentheses, after the subroutine invocation, like this:
$n = &max(10, 15); # This sub call has two parameters
That list is passed to the subroutine; that is, it's made available for the subroutine to use however it needs to. Of course, this list has to be stored into a variable, so the parameter list (another name for the argument list) is automatically assigned to a special array variable named @_ for the duration of the subroutine. The subroutine can access this variable to determine both the number of arguments and the value of those arguments.
So, that means that the first subroutine parameter is stored in $_[0], the second one is stored in $_[1], and so on. But -- and here's an important note -- these variables have nothing whatsoever to do with the $_ variable, any more than $dino[3] (an element of the @dino array) has to do with $dino (a completely distinct scalar variable). It's just that the parameter list must be stored into some array variable for the subroutine to use it, and Perl uses the array @_ for this purpose.
Now, you could write the subroutine &max to look a little like the subroutine &larger_of_fred_or_barney, but instead of using $a you could use the first subroutine parameter ($_[0]), and instead of using $b, you could use the second subroutine parameter ($_[1]). And so you could end up with code something like this:
sub max {
# Compare this to &larger_of_fred_or_barney
if ($_[0] > $_[1]) {
$_[0];
} else {
$_[1];
}
}Well, as we said, you could do that. But it's pretty ugly with all of those subscripts, and hard to read, write, check, and debug, too. We'll see a better way in a moment.
There's another problem with this subroutine. The name &max is nice and short, but it doesn't remind us that this subroutine works properly only if called with exactly two parameters:
$n = &max(10, 15, 27); # Oops!
Excess parameters are ignored -- since the subroutine never looks at $_[2], Perl doesn't care whether there's something in there or not. And insufficient parameters are also ignored -- you simply get undef if you look beyond the end of the @_ array, as with any other array. We'll see how to make a better &max, which works with any number of parameters, later in this chapter.
The @_ variable is local to the subroutine;[106] if there's a global value in @_, it is saved away before the subroutine is invoked and restored to its previous value upon return from the subroutine.[107] This also means that a subroutine can pass arguments to another subroutine without fear of losing its own @_ variable -- the nested subroutine invocation gets its own @_ in the same way. Even if the subroutine calls itself recursively, each invocation gets a new @_, so @_ is always the parameter list for the current subroutine invocation.
[106]Unless there's an ampersand in front of the name for the invocation, and no parentheses (or arguments) afterward, in which case the @_ array is inherited from the caller's context. That's generally a bad idea, but is occasionally useful.
[107]You might recognize that this is the same mechanism as used with the control variable of the foreach loop, as seen in the previous chapter. In either case, the variable's value is saved and automatically restored by Perl. We'll see this again with the local operator later in this chapter.
|  | |
| 4.4. Return Values |  | 4.6. Private Variables in Subroutines |
Copyright © 2002 O'Reilly & Associates. All rights reserved.