The first call shouldn't see the initialization because the straight-line code has a function call before my has been defined, and one after. Now should it matter where my is? How about these?my $foo; print_foo(); $foo = "Hello\n"; print_foo(); sub print_foo {print $foo;}
When Perl first sees those it may not be able to even attempt to do the assignment.my %data = default_data(); sub whatever { my $self = shift; # ... }
Perl uses a very simple rule. There is stuff that it takes care of when it parses and compiles the file, and there is stuff that it takes care of when it executes. Figuring out what function to call and what variable is which is part of parsing and compiling. Actually doing things with those variables (like assignment and function calls) are taken care of at executation, which means that they have available to them other things that have happened already while executing, and the definitions of everything in your code.
What it also means is that function calls don't see assigments that haven't happened already. In other words Perl does actions in the order it sees them. Not very surprising at all when you think about it like that!
Now for your problem there are two obvious solutions. One is to move the functions and private data into its own module. Now you load and initialize that data in one obvious step. The other is to memoize your data lazily like this:
This is something that tye and I have disagreed on for a bit. Personally I never use BEGIN in the way that he does, and I have yet to find a situation where I didn't find the above two solutions sufficient.{ my %private_stuff; sub some_func { unless (%private_stuff) { %private_stuff = qw(some defaults); } # ... } }
In reply to Re (tilly) 3: Perl Turning a Blind Eye
by tilly
in thread Perl Turning a Blind Eye
by tadman
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |