The explanation: when you "use Fred", and Fred.pm exports symbols, these only go into the namespace which is current when you issue "use Fred". They don't go to all namespaces. Consider the following:

Snark.pm

package Hunting::Snark;
use Bellman qw(foo bar);

# Bellman's exported symbols go into namespace Hunting::Snark
# hence &Hunting::Snark::foo is aliased to &Bellman::foo

package Boojum;

foo(); # is an undefined subroutine. There is no &Boojum::foo
[download]

Why I was mentioning that you need to declare a package first before you use things, is that otherwise, any exports will go into main:: not where you want them to. If you declare the package first and immediately above, Exporter will put the symbols into the namespace of the package just declared.

In terms of fixing your problem, you can add another use statement in the new namespace. This won't re-read the module as it has already been flagged as having been loaded, but the use will redo the Exporter functionality.

...
package Boojum;
use Bellman qw(foo bar);

foo(); # &Boojum::foo is now defined. aliased to &Bellman::foo
[download]

There's a lot going on here, so I want to pick things apart to understand the mechanics. First, your code has:

package Hunting::Snark;
use Bellman qw(foo bar);

# Bellman's exported symbols go into namespace Hunting::Snark
# hence &Hunting::Snark::foo is aliased to &Bellman::foo

package Boojum;

foo(); # is an undefined subroutine. There is no &Boojum::foo
[download]

First, why would you have two package statements in a file? that is, I know you can, but I don't see how that alludes to the situation I described (because I'm not doing that). Are you saying that your example illustrates effectively what happens when you use multiple use statements that call other packages into the current file, which is also a package? Is that effectively what I'm doing when I'm doing this:

package Hunting::Snark;
use Bellman qw(foo bar);
use Boojum qw(baz etc);
foo(); # is an undefined subroutine. There is no &Boojum::foo
[download]

If this is the case, I don't see how any of my code should be working, because (as my first example illustrated), I'm importing packages all over the place, and each of them imports each other. Could it all have been just dumb luck that I haven't started running into this problem more? As my modules are growing, I'm finding this is popping up more frequently.

What I assumed--and what I'd like to eventually get to--is a way to just have each of my packages have their own uniquely defined functions, export them, and have anyone that uses them simply call them by name without having to clutter up the code with Package::func()-style cruft.

Now, since that's how I've been operating, and it seems that's not going to be possible (which I'll accept), what's the next best thing? what sort of coding styles might I adopt to alleviate this problem and still have my code look elegant and easy to read/edit by others?

Dan Heller
http://www.danheller.com

No, my discussion was dealing with the case of multiple "package" statements in one .pm file. The code you cite won't get an undefined sub but will pick up Bellman::foo. Sorry if this wasn't clear.

Now, since that's how I've been operating, and it seems that's not going to be possible (which I'll accept), what's the next best thing? what sort of coding styles might I adopt to alleviate this problem and still have my code look elegant and easy to read/edit by others?

Consider an object orientated approach. This avoids package namespace problems, as objects carry their own class (namespace) with them. see perlboot perltoot and perlobj for more on this subject.

--

Oh Lord, won’t you burn me a Knoppix CD ?
My friends all rate Windows, I must disagree.
Your powers of persuasion will set them all free,
So oh Lord, won’t you burn me a Knoppix CD ?
(Missquoting Janis Joplin)