On Thu, Mar 20, 2008 at 1:13 PM, Gunnar Hjalmarsson <[EMAIL PROTECTED]> wrote: snip > > First off, don't do that. Messing around with another package's > > variables ties you to that version of the module and is bad juju. > > Not sure I understand how the OP's question motivates that remark. snip
Packages are normally used to implement modules. Modules are discrete pieces of code that should not depend on the internal workings of other modules or the scripts that use them. By modifying a variable in another package the OP is breaking the encapsulation that packages are there to provide. While it can be done it is an incredibly bad idea. See below. > > > > To get the output you desire use the our function to declare $name > > in Fred > > Even if that solution 'works', it results in the warning ""our" variable > $name masks earlier declaration in same scope". The reason is that our() > is lexically scoped, not package scoped. > > Please consider this example: > > C:\home>type test.pl > use warnings; > use strict; > > my $name = 'sanket'; > $Fred::name = 'Fred'; > > print "$name\n"; > > package Fred; > our $name; > print "$name\n"; > > package main; > print "$name\n"; > > C:\home>perl test.pl > "our" variable $name masks earlier declaration in same scope at test.pl > line 9. > sanket > Fred > Fred > > C:\home> > > The third print() statement, even if within package main, outputs the > package variable $Fred::name. In other words, since the our() > declaration in package Fred is not restricted to a block, it's effective > from the point of its location and throughout the rest of the file. snip Interestingly enough, I don't get that warning with 5.8.8 (but I do see the behavior). It looks like it was added in 5.10. This is an issue, but only if you use multiple packages in one file (not common outside of OO code that shouldn't need our in the first place), you reopen a previous package, and you forget to limit the scope of the other packages with braces. Gee, you do something uncommon and inadvisable and get bitten by it. This is why good style dictates that packages should go in their own files (with the possible exception of helper classes in OO code). Perl lets you do many dangerous and stupid things, but that doesn't mean you should do them. -- Chas. Owens wonkden.net The most important skill a programmer can have is the ability to read. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/
