I wouldn't inherit from Exporter at all, so I would get rid of @ISA=qw(Exporter). Exporter can export its own import() function into your module since v5.57 == Perl 5.8.3 (released 2004-01-14), so there is no need to inherit from Exporter any more. I would not use require, because it requires more typing than use and it is processed at runtime, not at compile time. use Exporter 'import'; is all you need to use Exporter's features from your module. Fall back to ...

use Exporter; 
use vars qw(@ISA @EXPORT);

@ISA=qw(Exporter);
@EXPORT=qw( ... );
[download]

... only if you need to support really old Perl versions.

Note that there are several Exporter replacements, Sub::Exporter has some very interesting features, but it can export "only" subs, no variables.

Regarding style, I prefer the following: pragmas first, followed by core and CPAN modules, followed by my own modules (mostly application specific). So, a typical module would look like this:

package MyApp::Foo;

use strict;
use warnings;
use parent 'MyApp::BaseClass'; # only for OOP classes

use Carp qw( croak ); # only when needed
use DBI;              # only when needed
use CGI;              # only when needed

use MyApp::Tools;
use MyApp::Utils;

our $SVNID=q$Id$;                                # SVN expands this li
+ne
our $VERSION=sprintf('%d',q$Revision$=~/(\d+)/); # SVN expands this li
+ne

our @EXPORT=qw( ... );    # not for OOP classes, only when needed
our @EXPORT_OK=qw( ... ); # not for OOP classes, only when needed
our %EXPORT_TAGS=( ... ); # not for OOP classes, only when needed

# more globals, if required

# subs here

1;
[download]

Alexander

Firstly, do you need to export anything? If your module has an OO interface, then users will typically do:

use Your::Clever:Module;

my $instance = Your::Clever:Module::new()
$instance->some_function();
[download]

Secondly, if you read the POD for Exporter, then near the bottom they list a number of alternatives, many of them look much nicer. Exporter is an old module, and a lot of other stuff has come since, some of it will be better.

Having said that, I don't think it makes any difference. My gut feeling is that none of it matters until perl gets to the end of your source file (or package), and then considers everything at once. In other words it is just a style thing like tabs vs spaces for indent, and you should do what ever you or your local coding conventions prefer.

For myself, I am thinking that you have to use or require the exporter module, so it makes sense to put that use along with all the others, and then set-up the exports afterwards, Then again, I have just taken a look at some old perl I wrote about 8 years ago, and it is the other way around. I guess it makes no difference.

Actually users should never:

my $instance = Your::Clever:Module::new();
[download]

Instead they should:

my $instance = Your::Clever:Module->new();
[download]

which works better with inheritance and is more robust against changes to the OO hierarchy.

True laziness is hard work

1. Some other module or program uses your module.
2. During its compilation, the perl compiler encounters "use Module1";
3. This triggers your module to get compiled; while doing so, Module2 and Module3 will get compiled (if not already compiled). Module2->import and Module3->import will be called.
4. Your module will run. First thing it does is to compile Exporter (if it hasn't been compiled already).
5. Then Module1->import is called (assuming that other module or program uses "use Module1"). Which means Exporter::import is called.
6. Exporter::import exports fn1 and fn2 to the calling module or program.
7. Perl will resume compiling the calling module or program.

I've never understood why people use the idiom 'require Exporter'. I never do. 'use Exporter();' also compiles Exporter without calling import.

Ah, thanks!

I forgot those two. I suppose they have to go before the line 'require Exporter'? How about the other modules (Module1, Module2)?

Thanks everyone!

I didn't know that

require Exporter;
our  @ISA = qw(Exporter);
[download]

I didn't know that require Exporter; our @ISA = qw(Exporter); is outdated code.

And how should you know that?

The synopsis of Exporter still (as of v5.63 found on CPAN) has this code as the very first example. The shorter and cleaner use Exporter 'import'; is the second example, and no word in the synopsis explains the differences. Even in the "Good Practices" section linked from the synopsis, all of the examples inherit from Exporter. Importing Exporter::import is explained in just four sentences hidden in "Advanced Features" -> "Exporting without inheriting from Exporter".

I think the Exporter documentation needs some patches, explaining the difference. It also should tell people not to inherit from Exporter in new code. Perhaps all of the inheritance stuff should be moved to a "legacy usage" section.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

On the other hand, there's something to be said for reading all the documentation of a module you want to use.

You find little gems like: use Some::Exporting::Module '/./';

i'm a little late for this threads.. I never understood such thing about Exporter.. anyway the docs have been updated in this while:
Exporting-Without-Inheriting-from-Exporter

thanks
L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

Oh wow, that merits a weekly announcement in perlnews