The BEGIN block looks useless to me. Its only important effect in the first version is to limit the scope of the variables declared with our. In the second version it does nothing useful.

On our vs use vars, I do not consider vars obsolete. What it does it does better than our does. See Why is 'our' good? for more detail on why I think that.

The parens after Exporter is a subtle micro-optimization, they avoid calling Exporter::import when it will be doing nothing. You can do it if you want - it certainly doesn't hurt - but I usually don't worry about things like that unless performance is a known problem.

I'd suggest a template that looks something like this:

package Foo;
use Exporter;
@ISA = qw(Exporter);
@EXPORT_OK = qw(); # Exportable things go here
$VERSION = 0.01;
use strict;

# Functions etc go here.
 
1;

__END__

=head1 NAME

Foo.pm - What is it?

=head1 SYNOPSIS

  use Foo;
  # Do something with it.

=head1 DESCRIPTION

Yada, yada.

=head1 EXAMPLES

=head1 AUTHOR
[download]

Note the trick of putting the special variables before strict.pm, eliminating any need to bother declaring them.

Doesn't that "trick" make sections of the code position dependant? Doesn't that at least warrent a comment explaining that?

I think that either our or use vars is preferable.

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

And here I was under the impression that my pointing out the trick was a comment.. :-D

Seriously now, you're right that it does make that section of the code depend on position. Which I don't see as a horrible thing - no worse than a lexically scoped variable. And certainly not in boilerplate initialization code which many people who use it won't expect to understand.

If you're uncomfortable with that fact you can always declare the variables as is usually done. In fact I pointed out that I'd done it so that people could make that choice.

Also I deliberately didn't comment on the mechanics. If I thought that the mechanics required commenting on within the code, then I'd first try to solve that by changing the mechanics, not commenting the code.

Re item 2: Check out the node inheritance problems for an example of where BEGIN { @ISA = ... } was useful.

Re item 3: BEGIN { use ... } is redundant.
use Module; is about equiv to BEGIN { require Module; Module->import(); }
use Module (); is about equiv to BEGIN { require Module; }
use Module qw(list); is about equiv to BEGIN { require Module; Module->import(qw(list)); }

I'd leave most of the things out of the BEGIN blocks because most of them will already happen at compile time.

I'd do this for an OO module

package My::Package;
use strict;

use vars qw( $VERSION );
$VERSION = 0.01;

# If you inherit from some other module (use sparingly):
#use base qw( ... );
[download]

or, if you use inheritance (I've become more suspicious of base.pm even though I hardly ever use it since I hardly ever use inheritance in Perl):

package My::Package;
use strict;

use vars qw( $VERSION @ISA );
BEGIN {
    $VERSION = 0.01;
    @ISA = qw( ... );
}
[download]

where the BEGIN block shouldn't be needed for "normal" module situations but can be useful in unusual situations (that are often better to just avoid).

For a non-OO module:

package My::Module;
use strict;

use vars qw( $VERSION @EXPORT_OK %EXPORT_TAGS );
BEGIN {
    $VERSION     = 0.01;
    @EXPORT_OK   = qw( ... );
    %EXPORT_TAGS = ( ... );
    require Exporter;
    *import = \&Exporter::import;
}
[download]

where (again) the BEGIN is usually not needed. Remove %EXPORT_TAGS if you don't use it (it is useful if your module supports exporting groups of symbolic constants).

Inheriting from Exporter to just get an import() is a bad idea. It means you get *all* methods that Exporter defines even the ones you didn't even know about. This over-use of inheritance has lead to lots of modules using "autoloading" w/o having been designed to use autoloading which means that a simple mispelling of a method name gives a cryptic error about not finding some "*.al" file (which makes you think you've installed the module incorrectly rather than that you've mispelled a method name).

I don't use our, it makes code less backward compatible, it is confusingly complex (though often doesn't appear that way on the surface), and it is easy to abuse.

You can also add "use warnings;" after "use strict;", though there are also good reason to not do that. I'm a big fan of warnings being on during development but leaving them on in production is a net loss in my book unless you do the hard work of setting up the back channel so that the information from the warnings gets back to the developers and does't annoy the users. (And warnings.pm isn't included in versions of Perl that have now become rather old.)

Shameless self-plug: Given that there are many different individual styles for writing module distributions, please consider ExtUtils::ModuleMaker::TT, which extends ModuleMaker to allow user-defined templates for all the skeleton files of a distribution using the Template Toolkit and a pre-defined configuration file with default settings for ModuleMaker. I wrote it to work out some frustrations with the cumbersome process of creating module distributions with the standard tools and then having to edit all the boilerplate. As always, any feedback would appreciated.

-xdg

Code posted by xdg on PerlMonks is public domain. It has no warranties, express or implied. Posted code may not have been tested. Use at your own risk.

FYI, Module::Starter will handle the TT.

xoxo,
Andy

Are you writing plain reusable modules, or object-based modules. In object-based modules, you rarely need or want to use Exporter. You'll still want/need $VERSION and @ISA, but the rest of the variables can go.

If you're not using object-based modules, you still don't necessarily need Exporter, but it can be nice. If you still use it, it wouldn't hurt to delete @EXPORT entirely.

As for who can take advantage of it ... well, other BEGIN blocks, CHECK blocks, INIT blocks ... again - I've never written a CHECK or INIT block in my career, and don't think I ever will. (Not in Perl5, at any rate.)

I don't know the history behind this construct, but I'm thinking it's very cargo-cultish.

BEGIN is the sort of thing you write when you have code-generation tasks or want to otherwise have done work appropriate to a compile-time categorization. I wouldn't ordinarilly include things like setting $VERSION in that though there is some sense in including Exporter specific information at compile-time (even though it isn't code generation) - other things that have to run at compile-time are allowed to care about that information so it is potentially relavent at that time.

I've had to use it to take care of cross-platform issues. Utilizing it to set up enviornmental vars and module libraries based on what OS the script is running in.