--- Nick Transier <[EMAIL PROTECTED]> wrote:
> Thanks, do you start the brackets before the "package blah" call, or
> after.
> I.E. is it {package blah; #stuff; } or package blah; {#stuff;} ?
It depends on how tightly private you want those variables.
I always put the package statement inside the brackets, but I can see
how someone might prefer the visual effect of putting it outside.
It's the same trick as Perl statics, the idiom for which is:
{ # open a block
my $var; # declare a my() var scoped to the block
sub func { # declare a (global) function in that scope
$var++; # the function can see $var
}
} # closes scope of $var, so nothing *else* sees it
The thing to remember is that the package statement tells perl that
until further notice, the code it finds while parsing the rest of the
"compilation unit" belongs to that namespace. From perldoc -f package:
package NAMESPACE
Declares the compilation unit as being in the given namespace.
The scope of the package declaration is from the declaration
itself through the end of the enclosing block, file, or eval
(the same as the my operator). All further unqualified dynamic
identifiers will be in this namespace. A package statement affects
only dynamic variables--including those you've used local on--but
not lexical variables, which are created with my. Typically it
would be the first declaration in a file to be included by the
require or use operator. You can switch into a package in more
than one place; it merely influences which symbol table is used
by the compiler for the rest of that block. You can refer to
variables and filehandles in other packages by prefixing the
identifier with the package name and a double colon:
$Package::Variable. If the package name is null, the main package
as assumed. That is, $::sail is equivalent to $main::sail (as
well as to $main'sail, still seen in older code).
If NAMESPACE is omitted, then there is no current package, and all
identifiers must be fully qualified or lexicals. This is stricter
than use strict, since it also extends to function names.
See perlmod/``Packages'' for more information about packages,
modules, and classes. See perlsub for other scoping issues.
The package can be in a block, and obviously can have blocks in it. =o)
__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/