 <p>The simple, and most likely correct answer is that the last module loaded that exports a given function will be the one whose function is used.</p> <p>When a function (or other symbol) is exported, the symbol table for the receiving package is modified. So if two import functions make changes to the table, the last change is what is preserved.</p> <p>Recall that <code>use Foo;</code> is <em>more or less</em> equivalent to <code>BEGIN { require Foo; Foo-&gt;import if Foo-&gt;can(import); }</code>.</p> <p>Since <code>import</code> is just a subroutine with a special name, the only limitation is the twisted imagination of J. Random Hacker. <code>import</code> can be <strong>any</strong> code. It can do anything or nothing. For example, it could contain logic to make sure no already defined functions are over-written.</p> <p>But, barring any weirdness, the last loaded will be the one in use.</p> <hr> <p>To be 100% technically correct, <code>use Foo;</code> is equivalent to <code>BEGIN { require Foo; Foo-&gt;import; }</code>. </p> <p>Except that this code doesn't work like you might expect. </p> <p><strong>Where the exact code varies from my example.</strong></p> <p>What the above code does is tied up in how method resolution works in Perl.</p> <p>Ordinarily, a call to <code>Foo-&gt;some_sub</code> where <code>some_sub</code> does not exist and an <code>AUTOLOAD</code> function is defined in <code>Foo</code>, <code>some_sub</code> would be handled by the <code>AUTOLOAD</code> function. There is a special case for <code>import</code> that exempts it from <code>AUTOLOAD</code> checks. See <a href="http://perldoc.perl.org/perlsub.html#Autoloading" rel="nofollow">perlsub on Autoloading</a>. </p> <p>After <code>AUTOLOAD</code> has (or really has not) been checked, we check inheritance. The same check for matching functions or an <code>AUTOLOAD</code> function is repeated for each item in the original package's <code>@ISA</code>. This is a recursive process that includes the parent's parents and so forth until the entire inheritance tree is checked--<code>@ISA</code> is checked in left to right, depth first order. All this time the <code>AUTOLOAD</code> exception is in place and it will be skipped for <code>import</code>.</p> <p>Eventually, if no matching method is found, we fall back on <code>UNIVERSAL</code> the universal base class. If the function exists in <code>UNIVERSAL</code>, it is called, otherwise we throw an exception that says the function couldn't be found.</p> <p>So, in the case of our <code>Foo-&gt;import;</code> call, <code>UNIVERSAL::import</code> is called to handle the job. So, what does this function do?</p> <p>In Perl 5.12.2 the code looks like this:</p> <pre><code>sub import { return unless $_[0] eq __PACKAGE__; return unless @_ &gt; 1; require warnings; warnings::warnif( 'deprecated', 'UNIVERSAL-&gt;import is deprecated and will be removed in a future perl', ); goto &amp;Exporter::import; } </code></pre> <p>Note that the first thing the function does is bail out if it wasn't called on <code>UNIVERSAL</code>.</p> <p>Now everything I've said is true, as long as you don't do several things:</p> <ul> <li><p>override the method resolution order. If you do this then method resolution will happen however you have defined it to. Whether we get to UNIVERSAL or not or when is totally up in the air and subject to your whims.</p></li> <li><p>override <code>UNIVERSAL::import</code>. You could monkey patch UNIVERSAL::import to do whatever you want. Again how this will behave is completely subject to your whims.</p></li> </ul> <p>So, the semi-equivalent code I gave above is a just shorthand for what happens. I thought it would be easier to understand, since it does not require knowing as many details of how Perl does things, but it isn't 100% equivalent to what really happens. Doing unexpected things breaks the equivalence. </p> <p><strong>Where my code varies from exact equivalent code</strong></p> <p>Further, my code calls <code>Foo-&gt;can</code> which generally falls back to <code>UNIVERSAL::can</code>. In no place is <code>can</code> called in the normal chain of events. This gets especially hairy when one considers the issues with <code>can</code> in Perl. </p> <ul> <li><code>can</code> may be overridden or reimplemented by any class in the inheritance graph. Which <code>can</code> gets called is subject to method resolution order. All the problems with multiple inheritance apply here.</li> <li><code>can</code> does not see autoloaded functions. Since autoloading doesn't apply to import this may not seem like a big deal. The problem is that it is considered good practice to overload <code>can</code> to take this into account if you use autoloading. So, this compounds the issues above. The best thing to do is to use the non-core module <code>NEXT</code> to enable method redispatch, so that can can be handled by each module in the chain. Unfortunately, this is rarely done.</li> </ul> <p><strong>Conclusion</strong></p> <p>All this is one hell of a lot to chew on.</p> <p>You can accept my shorthand, knowing that in some cases, it is not exactly correct. </p> <p>Or you can accept the actual code, that has its own set of exceptions.</p> <p>Either way, if you break through the surface of either example there are some subtle issues to cope with.</p>