Problems? Is your data what you think it is? | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
use strict forces you to provide scoping information about
your variables. Hence:
will generate compile time errors because we haven't told Perl about the scope of the $global variable. Now there are several ways we can declare variables in Perl, and of course they mean different things. use vars, and our give globals: These can then be used anywhere in their package as you'd expect of globals. They can also be accessed outside of the package by fully qualifying them. eg fully qualifying variables gives globals. Kinda like the above, and your example. In your code you're created a new namespace (global) and using that for your globals. Yes, it is ugly, but it's perfectly valid. my localizes variables to their block. local temporarily displaces the value of a variable until the end of the block Be careful of declaring a local variable of the same name as a another variable previously declared with my in the same scope. It should complain, and it does. That is:
The difference between my and local is a subtle one. Local variables exist for that call stack, until the end of the block. So if your block calls subroutines, the localised variable will exist within those subroutines (and any subroutines they call and any they call and so on - which can cause nasty surprises). Variables declared with my exist _only_ within their block. This means that if the block calls a subroutine that is not defined within the same block, then that subroutine does not automatically get access to the variable (but you can pass it in as an argument). Excepting these, you cannot access variables declared within a block, at all, from outside that block. That is: will result in a compile time error. Phew! I hope that helps. Jacinta. In reply to Globals, localisation and strict.
by jarich
|
|