Re^5: error for undefined function that's been imported

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]

--

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)

Comment on Re^5: error for undefined function that's been imported Select or Download Code

Replies are listed 'Best First'.
Re^6: error for undefined function that's been imported by argv (Pilgrim) on Aug 16, 2005 at 05:11 UTC
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	[reply] [d/l] [select]
Re^7: error for undefined function that's been imported by rinceWind (Monsignor) on Aug 16, 2005 at 20:24 UTC
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)	[reply]
Re^8: error for undefined function that's been imported by argv (Pilgrim) on Aug 17, 2005 at 07:24 UTC
So, let me embarrassingly get back to basics for a sec. I'm pretty familiar with oo programming, but none of that applies to anything I'm doing in this particular project. The issue I'm dealing with is simply that I have a bunch of different functions separated (into different files) based on the nature of their purpose. In other words, I'm creating what I'd like to call a bunch of libraries of functions (and exported variables), not a bunch of objects and classes. I chose to implement these libraries in the form of Packages because I figured that would be efficient for perl and yield better execution performance for the apps that call them. But, given what I'm running into, I think I've chosen the wrong approach. So, since I don't need classes or objects, but I do need to create libraries, what's a more appropriate approach using perl? Dan Heller http://www.danheller.com	[reply]