I think ... it won't print ...
You think? What happens when you do it?
Note that the behavior of this code depends on execution order. The execution order Sb; Sa; will have very different results, at least the first time. Try it!c:\@Work\Perl\monks>perl -wMstrict -le "my @ra; ;; sub Sa { @ra = (1,2,3); } ;; sub Sb { foreach my $n (@ra) { print $n; } } ;; Sa; Sb; " 1 2 3
Update: How could you make this code immune to execution order problems? One way might be:
The @ra array is defined within a lexical scope and is completely inaccessible to any code outside the scope (except by deep magick — but you didn't hear that from me). An initialization state exists for @ra that is checked on every invocation of the S_doit() subroutine; if the array isn't initialized, initialize it before doing anything else.c:\@Work\Perl\monks>perl -wMstrict -le "{ my @ra; ;; sub S_init { @ra = (1, 2, 3); } ;; sub S_doit { S_init() if @ra == 0; foreach my $n (@ra) { print $n; } } } ;; S_doit(); " 1 2 3
Unfortunately, this imposes the burden, which may not be small, of checking the state of @ra (and who knows what else) on every S_doit() invocation. Is there a way to avoid this overhead? This
does lexical initialization at compile time and avoids the need for further thought about what happens at run time. (Update: See BEGIN, UNITCHECK, CHECK, INIT and END in perlmod for info on BEGIN (and the related INIT) blocks.)c:\@Work\Perl\monks>perl -wMstrict -le "BEGIN { my @ra = (1, 2, 3); ;; sub S_doit { foreach my $n (@ra) { print $n; } } } ;; S_doit(); " 1 2 3
Of course, with techniques like these, you're edging closer and closer to a full-on Object Oriented Programming approach, so why not just take the plunge?
Give a man a fish: <%-{-{-{-<
In reply to Re^3: Accessing values outside subroutine
by AnomalousMonk
in thread Accessing values outside subroutine
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |