Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

Re^2: An Interesting Gotcha With use/require

by periapt (Hermit)
on Feb 09, 2005 at 17:11 UTC ( #429429=note: print w/replies, xml ) Need Help??

in reply to Re: An Interesting Gotcha With use/require
in thread An Interesting Gotcha With use/require

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.

use strict; use warnings; use diagnostics;
  • Comment on Re^2: An Interesting Gotcha With use/require

Replies are listed 'Best First'.
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.

      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)

      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.


        That only helps for modules that export anything. OO-modules typically export nothing, and hence, don't have an import module.
        But in order to know an import is missing, Perl first needs to compile the module. However, if Perl compiles the module, the "subroutine redefined" warnings are being thrown.

        You suggested check would have thrown another warning/error, but it wouldn't have eliminated the ones the OP was getting. I'm not sure that a warning "File::BaseName::import not found" would have been very helpful.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://429429]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (1)
As of 2017-08-17 02:57 GMT
Find Nodes?
    Voting Booth?
    Who is your favorite scientist and why?

    Results (278 votes). Check out past polls.