Re: Package Variables

Replies are listed 'Best First'.
Re^2: Package Variables by ELISHEVA (Prior) on Mar 28, 2011 at 04:00 UTC
Minor correction - my is block scoped (or more technically speaking "lexically" scoped) with the largest containing "block" (lexical unit) being the file. Example: `use strict; use warnings; package Goo; my $x=100; print "package=", __PACKAGE__, " x=$x\n"; package Boo; { my $x=200; print "package=", __PACKAGE__, " x=$x\n"; } package Foo; print "package=", __PACKAGE__, " x=$x\n"; #outputs package=Goo x=100 package=Boo x=200 package=Foo x=100` [download]	[reply] [d/l]
Re^2: Package Variables by kurt2439 (Sexton) on Mar 27, 2011 at 19:40 UTC
I didn't know that about the Config.pm perl module -- thanks. I didn't know that 'my' was scoped to a file, however I have tried using 'our' in the separate Config.pm file and it still doesn't work either. Only when the "package" is in the same file does 'our' work. Any shouldn't 'my' work in that situation as well? I just renamed my module to 'Config11.pm' and it works fine now. What a drag -- I didn't realize that Config.pm would collide. Why didn't perl warn me that I was stepping on a built in package of core significance? Or did perl just include the core "Config.pm" module and mine never actually got loaded?	[reply]
Re^3: Package Variables by Anonymous Monk on Mar 27, 2011 at 19:52 UTC
Why didn't perl warn me that I was stepping on a built in package of core significance? Or did perl just include the core "Config.pm" module and mine never actually got loaded? How would perl know that this is unintentional? If you write a new program and name it perl.exe, would your OS warn you that ./perl.exe is not C:\Perl\bin\perl.exe? @INC managment is like @PATH managment, the assumption is you know what you're doing $ cat Config.pm package Config; $VERSION=666666; 1; $ perl -MConfig -le " print $INC{q!Config.pm!}" C:/perl/5.12.2/lib/MSWin32-x86-multi-thread/Config.pm $ perl -le "print for @INC" C:/perl/site/5.12.2/lib/MSWin32-x86-multi-thread C:/perl/site/5.12.2/lib C:/perl/5.12.2/lib/MSWin32-x86-multi-thread C:/perl/5.12.2/lib . $ perl -I. -MConfig -le " print $INC{q!Config.pm!}" Config.pm $ perl -I. -le "print for @INC" . C:/perl/site/5.12.2/lib/MSWin32-x86-multi-thread C:/perl/site/5.12.2/lib C:/perl/5.12.2/lib/MSWin32-x86-multi-thread C:/perl/5.12.2/lib . [download]	[reply] [d/l]
Re^4: Package Variables by kurt2439 (Sexton) on Mar 28, 2011 at 04:12 UTC
I see your point, but still why not warn me? Perl warns me if I declare the same variable name in the same scope even though I may know what I'm doing. It seems like the way the perl warnings pragma operates. It's not like I am doing something hard to predict like overriding some 3rd party CPAN module. This is an expected, core perl module no?	[reply]
Re^5: Package Variables by Anonymous Monk on Mar 28, 2011 at 07:23 UTC
Re^6: Package Variables by kurt2439 (Sexton) on Mar 28, 2011 at 12:48 UTC
Re^3: Package Variables by toolic (Bishop) on Mar 27, 2011 at 20:11 UTC
Why didn't perl warn me that I was stepping on a built in package of core significance? That would make a good Perl::Critic policy. There is already Perl::Critic::Policy::Subroutines::ProhibitBuiltinHomonyms. I wonder how tough it would be to create a policy to look for Core module names. Update: on second thought, this would not be possible. I think the only thing that can be done is use something like findpm to search for duplicate modules in @INC.	[reply]