A couple of things are going on here.

• You're not defining a package for Bozo

• You're not using Exporter correctly

The result is that when you first use Bozo, go_bozo gets compiled into the current package and the implicit call to import (normally handled by Exporter) does nothing. The second time, the file isn't actually compiled again, and there's still no import, so the sub doesn't get loaded to the new package space, either.

Here's how I'd write them:

package Bozo;                    # make it a package

use strict;
use warnings;

use base 'Exporter';             # subclassing with "base"
our @EXPORT = qw( go_bozo );     # "our" not "my"

sub go_bozo {
    return "BOZO!\n"
}

1;
[download]

package Foo;

use strict;
use warnings;

use Bozo;

sub Foo {
    return go_bozo()
}

1;
[download]

#!/usr/bin/perl

use strict;
use warnings;

use lib '.';

use Bozo;
use Foo;

print go_bozo();

print Foo->Foo();
[download]

Note that I've shifted the use lib just to the top level and did some minor rearranging. The real change is in Bozo.pm in how Exporter is used.

OK, I actually tried to add a "package" definition too (I didn't mentioned everything that I actually tried :), but it didn't help, actually it even got more confusing because from Foo.pm, even Bozo::go_bozo() wouldn't work then; so the lexical @EXPORT should really be the root of all evil in this case.

I know this must be frustrating, but once you do it a couple times, it will seem natural. Let me break it down a bit.

First, a use statement really does something like this behind the scenes:

# use Module @LIST is really:

BEGIN { 
  require Module; 
  Module->import( @LIST );
}
[download]

The require call will load a library file just like do, but only if it hasn't already been loaded. The call to the import method only happens if it is defined in the Module namespace (or is inherited).

So what if you don't have a package statement (and I'm leaving off strict, warnings and Exporter for space and clarity for the moment):

# Bozo.pm

sub go_bozo { return "BOZO!\n" }

1;
[download]

The first time you use Bozo, two things happen. First, Bozo.pm is loaded just like do. That means that go_bozo is compiled into the current package. For example:

# script.pl

package Burble;
use Bozo;

package main;
print Burble::go_bozo();
[download]

The second thing that happens it that Perl looks to see if it can call Bozo->import. Since no import is defined in Bozo, the call is skipped.

But the second time you use Bozo, require doesn't load it because it was already loaded, and the import still doesn't exist, so nothing happens.

# script.pl

package Burble;
use Bozo;

package Wibble;
use Bozo;

package main;
print Burble::go_bozo(); # OK
print Wibble::go_gozo(): # ERROR - doesn't exist
[download]

Now, add a package statement:

# Bozo.pm
package Bozo;

sub go_bozo { return "BOZO!\n" }

1;
[download]

Now, when you use Bozo the first time, go_bozo is compiled into the Bozo namespace rather that whatever namespace was in scope in the script file. (However, you still can't just call go_bozo because it hasn't been exported to the current package.)

# script.pl

package Burble;
use Bozo;

package main;
print Bozo::go_bozo();   # OK
print Burble::go_bozo(); # ERROR - doesn't exist
print go_bozo();         # ERROR - main::go_bozo() doesn't exist eithe
+r
[download]

Once you've got that clear, it's time to understand Exporter. Exporter provides the import function that's been missing. Prior to Perl 5.8, you needed to subclass Exporter like this:

# Bozo.pm
package Bozo;

# subclass Exporter
use Exporter;
@ISA = ( 'Exporter' );

sub go_bozo { return "BOZO!\n" }

1;
[download]

That can be done shorthand with base:

# Bozo.pm
package Bozo;

# subclass Exporter
use base 'Exporter';

sub go_bozo { return "BOZO!\n" }

1;
[download]

However, that still won't export go_bozo to the namespace that called use Bozo because you haven't told Exporter what you want to export.

# script.pl

use Bozo;

print Bozo::go_bozo();   # OK
print go_bozo();         # ERROR - main::go_bozo() still doesn't exist
[download]

Exporter requires you to put the functions you want to export into a package variable called @Bozo::EXPORT. (So, yes, the lexical is the root of evil -- but that's because Exporter specifically calls for a package variable.)

# Bozo.pm
package Bozo;

# subclass Exporter
use base 'Exporter';

# define exports
@EXPORT = ( 'go_bozo' );

sub go_bozo { return "BOZO!\n" }

1;
[download]

Now, when you use Bozo the first time, Bozo.pm is compiled, putting go_bozo in the Bozo namespace. But now, Bozo->import() is called, and exports go_bozo to the caller's namespace. The second time use Bozo is seen, the compilation isn't repeated, but the call to Bozo->import() is, which exports go_bozo again to the caller's namespace. So now you can do this:

# script.pl

package Burble;
use Bozo;

package Wibble;
use Bozo;

package main;
use Bozo;

print Bozo::go_bozo();   # OK
print Burble::go_bozo(); # OK
print Wibble::go_bozo(): # OK
print go_bozo();         # OK
[download]

Does that make more sense now? Without the package you wind up compiling the function into the file that calls use Bozo but only the first time. That looks like an export, but it's really not. With the package statement you then have to get the Exporter part right.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

1. Bozo.pm never defines a namespace (package Bozo;) so it's defining its function in main::, not Bozo::
2. Bozo.pm uses a lexical @EXPORT, not a package variable @EXPORT

# Bozo.pm
package Bozo;

use Exporter;
@Bozo::EXPORT = 'go_bozo';

sub go_bozo { return "bozo!" }

1;
[download]

# Foo.pm
package Foo;

use Bozo;

sub proxy { return go_bozo() }

1;
[download]

# prog.pl
use strict;
use warnings;

use Bozo;
use Foo;

print go_bozo();
print Foo::proxy();  # or Foo->proxy() if you want 'Foo' sent as the f
+irst arg...
[download]

Just a minor note on the difference in our solutions with respect to Exporter: Perl 5.6 and earlier require Exporter to be subclassed, not just imported.

use Exporter qw(import); # Perl >= 5.8
use base 'Exporter';     # Perl <= 5.6
[download]

Even my solution isn't backwards-compatible prior to Perl 5.6 because I included our and warnings. For personal use, this may not matter, but module authors who plan to publish should keep it in mind.

Update: For Perl >=5.8 I changed the example to note that you need to specify import.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

D'oh, right, oops. (Editor's note: I said those words out loud as I typed them.)

---

Jeff japhy Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and perl hacker
How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart

uh, our and use warnings work great in 5.6. I missed "prior to"

Is there any reason to prefer "use Exporter qw( import)" instead of the backward-compatible "use base 'Exporter'" when running perl 5.8 anyway ?

updated:we should use Exporter qw( import ) to get it to work :)

As I said in my reply to xdg, the package definition actually may be optional, but obviously that's the wrong @EXPORT scoping that killed me :) Shame...

It isn't optional. If you don't have package Foo; Foo is not a module. See Simple Module Tutorial.