standard perl module and BEGIN block.

hartzell has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: standard perl module and BEGIN block. by tilly (Archbishop) on Aug 16, 2004 at 19:09 UTC
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.	[reply] [d/l]
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]
Re^3: standard perl module and BEGIN block. by tilly (Archbishop) on Aug 16, 2004 at 21:18 UTC
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]
Re^4: standard perl module and BEGIN block. by BrowserUk (Patriarch) on Aug 16, 2004 at 21:47 UTC
Re^5: standard perl module and BEGIN block. by eric256 (Parson) on Aug 17, 2004 at 06:35 UTC
Some notes below your chosen depth have not been shown here
Re^5: standard perl module and BEGIN block. by ikegami (Patriarch) on Jun 12, 2010 at 19:00 UTC
Re^5: standard perl module and BEGIN block. (declaring vs. using globals) by tye (Sage) on Jun 12, 2010 at 16:53 UTC
Some notes below your chosen depth have not been shown here
Re: standard perl module and BEGIN block. by ikegami (Patriarch) on Aug 16, 2004 at 18:36 UTC
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)); }`	[reply] [d/l] [select]
Re: standard perl module and BEGIN block. (less) by tye (Sage) on Aug 16, 2004 at 20:28 UTC
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.) - tye	[reply] [d/l] [select]
Re: standard perl module and BEGIN block. by petdance (Parson) on Aug 16, 2004 at 22:12 UTC
Before you go too far down the road of a standard module template, please take a look at Module::Starter. It addresses many of the concerns of module templating, and it's extensible. xoxo, Andy	[reply]
Re^2: standard perl module and BEGIN block. by xdg (Monsignor) on Aug 17, 2004 at 14:37 UTC
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.	[reply]
Re^3: standard perl module and BEGIN block. by petdance (Parson) on Aug 19, 2004 at 17:01 UTC
FYI, Module::Starter will handle the TT. xoxo, Andy	[reply]
Re: standard perl module and BEGIN block. by hardburn (Abbot) on Aug 16, 2004 at 19:04 UTC
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. "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.	[reply] [d/l] [select]
Re: standard perl module and BEGIN block. by dragonchild (Archbishop) on Aug 16, 2004 at 18:29 UTC
I don't think I have used a BEGIN block more than 2-3 times in my career. shrugs YMMV. 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. ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]
Re^2: standard perl module and BEGIN block. by diotalevi (Canon) on Aug 16, 2004 at 18:48 UTC
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.	[reply]
Re: standard perl module and BEGIN block. by coreolyn (Parson) on Aug 16, 2004 at 18:41 UTC
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. coreolyn	[reply]


Syntactic Confectionery Delight
	PerlMonks