in reply to Re: Package Variables
in thread Package Variables

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?

Replies are listed 'Best First'.
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 .
      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?
        It isn't loading your Config.pm, so how would perl know to warn you?

        If on the other hand, you knew enough to use lib or -I to get perl to load your Config, you should know enough not to use already used names

        You could easily write something to warn you, using Module::Find, Module::CoreList, Module::Mapper, Module::Finder, Module::Locate, Devel::Modlist, Module::Which, Module::Which::List, so that

        use warnings::modulecollision;
        would warn you, but I don't know of any programming language that would try to do that by default, but I don't know of any languages that try to do this at all :)

        People seem to catch on pretty quick, its like house numbers, you can have many with the same number, as long as the street names are different :)

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.