> Your sub breaks encapsulation because it relies on the fact that @pics
> and $website are available in the sub but have not been passed into it.
> Generally we want our subs to take arguments and return values. If you
> were to move this sub to the top of the file or to another file (such as
> a library/module) it would break. So the first thing you should correct
> is the encapsulation by making your sub accept its arguments and return
> a value.
>
> sub links {
> my ($base_url, @list) = @_;
> foreach my $element (@list) {
> print .....
> }
> return;
> }
>
I have the Perl V3.0 CD Bookshelf (Much better than V4.0 IMHO) and this
makes sense now. Found this bit:
------------------------
4.6. Private Variables in Subroutines
But if Perl can give us a new @_ for every invocation, can't it give us
variables for our own use as well? Of course it can.
By default, all variables in Perl are global variables; that is, they are
accessable from every part of the program. But you can create private
variables called lexical variables at any time with the my operator:
sub max {
my($a, $b); # new, private variables for this block
($a, $b) = @_; # give names to the parameters
if ($a > $b) { $a } else { $b }
}
These variables are private (or scoped) to the enclosing block; any other
$a or $b is totally unaffected by these two. And that goes the other way,
too -- no other code can access or modify these private variables, by
accident or design.[108] So, we could drop this subroutine into any Perl
program in the world and know that we wouldn't mess up that program's $a
and $b (if any).[109]
-------------------------
--
Just getting into the best language ever...
Fancy a [EMAIL PROTECTED] Just ask!!!
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
