nysus has asked for the wisdom of the Perl Monks concerning the following question:

Monks,

If I import Module A and Module B into my program, their variables are now accessible to the current package without having to name them (e.g. $ModuleA::x). But what happens if Module A and Module B both a variable or subroutine with the same name? Let's say there is a &ModuleA::function and a &ModuleB::function and I call function(); from my program. How will my program know which function() subroutine to call?

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot";
$nysus = $PM . $MCF;

Replies are listed 'Best First'.
Re: Avoiding variable conflict when importing modules
by btrott (Parson) on Jun 25, 2001 at 02:40 UTC
    In this situation, whichever function sub was imported last will be called. If you have warnings enabled, you will get a warning when importing a function that has already been defined/imported; you won't get such a warning w/ a variable (at least I don't think you will).

    This is why you have to be careful when writing modules that export; you can easily trample someone else's namespace. Which is part of the reason why module authors are encouraged to use @EXPORT_OK instead of @EXPORT; you give the user of your module the choice of which functions/variables he/she imports, plus you make it very explicit to any reader of your code (including you :) which functions and variables you're importing. Ie. you can look at the use line and *know* what you're importing into your namespace.

[reply]
(tye)Re: Avoiding variable conflict when importing modules
by tye (Sage) on Jun 25, 2001 at 07:25 UTC

    With all of the bells and whistles in Exporter.pm, it is almost a shame that no provisions were made for renaming on import: 

    use ModuleA qw( function );
use ModuleB qw( operate=function );
function(); # calls ModuleA::function()
operate();  # calls ModuleB::function()

    [download]
    (no, this doesn't work)

    But you can roll your own rather easily, for example: 

    use ModuleB qw( function );
BEGIN { *operate= \&function; undef \&function }
use ModuleA qw( function );

    [download]
    There are certainly other ways to do it but I chose this way because it works with bizarre modules like CGI.pm and shouldn't trigger Exporter.pm's warning about exporting functions over the top of each other (if it has or will one day have such a warning). One disadvantage of this method is that you have to be careful of the order in which you use your modules.

            - tye (but my friends call me "Tye")
[reply]
[d/l]
[select]
Re: Avoiding variable conflict when importing modules
by chipmunk (Parson) on Jun 25, 2001 at 02:44 UTC
    The function that will be called is the one that was imported last. Importing is basically an assignment; a reference &ModuleA::function is assigned to the *main::{function} glob, and then a reference to &ModuleB::function is assigned to the same glob. The second assignment replacements the first one.

    This is why using @EXPORT_OK to specify what your module should export is safer and friendlier than using @EXPORT. With @EXPORT_OK, the person using the module has to specify the functions and variables to be imported, so he or she is more likely to notice any conflicts with other modules.

[reply]
Re: Avoiding variable conflict when importing modules
by Zaxo (Archbishop) on Jun 25, 2001 at 02:45 UTC

    It will use the one from the most recently useed module. If one is not found in the current package or its @ISA, it will fail to find any. If f() refers to $ModuleA::x explicitly, there will be no confusion and you get the one you want.

    After Compline,
    Zaxo

[reply]
[d/l]

Back to Seekers of Perl Wisdom