Re: An Interesting Gotcha With use/require

I had just added a library function to my general use library when I suddenly started getting a redefined subroutine warning for File::Basename (see below) from a program that had been running warning free until that moment. Both the main program and the new library function specify use File::Basename.

That should not be a problem if your library declares a package name. Don't make perl4-style libs that just dump all their functions into your main program -- you will regret it.

It was always my understanding that use and require would not try to load a module a second time if it was already listed in %INC.

They will still call import() a second-time though.

Comment on Re: An Interesting Gotcha With use/require

Replies are listed 'Best First'.
Re^2: An Interesting Gotcha With use/require by periapt (Hermit) on Feb 09, 2005 at 17:11 UTC
This is one of the points that made it interesting. File::Basename exports its functions by default. The library is a standard perl 5 formatted module with a seperately defined namespace that doesn't export anything by default. In particular, the offending library routine is not imported or used by the parent program. Yet the clash occurs. However, if I turn off the default export behavior of File::Basename (by importing with "use File::Basename();") in either or both of the routines, the problem goes away on its own. Not exactly what I was expecting. What namespace is the default behavior exporting too in this case? the parent? If the export is to different namespaces, why the clash? I see I forgot to include a package statement ahead of the subroutine declaration in my original post so I can see where you would think everything was occuring in the same namespace. My apologies for the confusion. PJ use strict; use warnings; use diagnostics;	[reply]
Re^3: An Interesting Gotcha With use/require by Anonymous Monk on Feb 09, 2005 at 18:02 UTC
As you can read in the followup to perrins comment, his comment is totally irrelevant, and only causes confusion. Your problem occurs because a subroutine gets defined twice. It has nothing to do with importing. See my example further down the thread - the one subroutine that's being redefined isn't exported.	[reply]
Re^4: An Interesting Gotcha With use/require by demerphq (Chancellor) on Feb 10, 2005 at 07:16 UTC
Th thing I find interesting is that one useful solution to this problem that I can think of has everything to do with import. If the op had written: `use File::BaseName qw(basename)` [download] then Perl could add a sanity check to its internal import() call to throw an error if import is missing but args have been provided as its almost certainly an error of some sort. Of course it doesnt right now, but it IMO it should. --- demerphq	[reply] [d/l]
Re^5: An Interesting Gotcha With use/require by Anonymous Monk on Feb 10, 2005 at 09:17 UTC
Re^5: An Interesting Gotcha With use/require by Anonymous Monk on Feb 10, 2005 at 11:07 UTC
Re^2: An Interesting Gotcha With use/require by Anonymous Monk on Feb 09, 2005 at 15:21 UTC
That should not be a problem if your library declares a package name. What do you mean by that? Note that `File::Basename` is a standard module whose first line reads: `package File::Basename;` [download] The problem isn't the library. The problem isn't the code either. The problem is the underlaying filesystem. `To the OP: "Here's a nickle kid. Get yourself a better computer"`	[reply] [d/l]
Re^3: An Interesting Gotcha With use/require by perrin (Chancellor) on Feb 09, 2005 at 15:56 UTC
Not File::Basename, but his library that uses it. There would not be any collision of imported names if that library was in a different namespace.	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.

use strict; use warnings; use diagnostics;