in reply to standard perl module and BEGIN block.

The perlmod man page is showing every piece that you might want to include. Most of them you do not need to include in any given module. Furthermore as a best practice I strongly suggest not including @EXPORT or %EXPORT_TAGS.

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.

Replies are listed 'Best First'.
Re^2: standard perl module and BEGIN block.
by BrowserUk (Patriarch) on Aug 16, 2004 at 19:35 UTC
    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
[reply]
[d/l]
      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.

[reply]

        My thinking that a comment in the boiler plate code would be appropriate as once code gets into a module, those coming along after may not appreciate it's source or significance.

        Avoiding globals all together would be the best route, but that's not currently possible for the likes of these "special variables".

        For a long time I didn't really appreciate your concerns regarding our, but having quite recently been bitten by a typo in an our var, they can indeed cause mysterious problems.

        I guess what I would really like, whilst doing away with globals completely is not an option, would be a combination of the two; use vars; and our.

        The former would indicate those globals I intended to use and disable the warnings/strictures on them--but only within those scopes where I had used our for that same variable.

        Using our for a var that hadn't previously been declared with use vars would raise an error. As would attempting to use a global mentioned in use vars, without also having scoped it using our.

        I'm not really a S&M type, and that does sound like "belt & braces" even to me, but given my propensity for typos, and the number of saves that "Global symbol "$x" requires explicit package name.." makes on my behalf, I would welcome this ability.

        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
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom