standard require

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

Hi --

Each module or program I'm writing as part of a larger system starts with the same litany of 'use' code. I feel like I am typing the same structural code over and over, then woe to me should I need to make a change (as when I recently decided to use the warnings pragma throughout).

use strict; 
use warnings;

package Foo::Bar;

use Data::Dumper;
use Log::Log4perl;
my $log = Log::Log4perl->get_logger(__PACKAGE__);
use MyDBI;
use MyLWP;
etc etc etc
[download]

Would it be considered Bad Form to toss all of these into a Common.pm file and then require them? My thought is to start each module with

package Foo::Bar;
require Common;
[download]

Any pitfalls of this? Would I want a "use" or a "require" here? Would each package get their own copy of $log with the correct package name?

Thanks for your advice.

rkg

Comment on standard require Select or Download Code

Replies are listed 'Best First'.
Re: standard require by broquaint (Abbot) on Apr 23, 2003 at 10:10 UTC
Would it be considered Bad Form to toss all of these into a Common.pm file and then require them? IMHO, no (not that it makes much difference since you can only ever require a module once (without munging `%INC`, of course)). However this won't work for lexically scoped pragma such as `strict` and `warnings`, as they will only apply their particular pragmatic effects to the given lexical scope. So you will have to explicitly include the likes of `strict` into your desired modules. You'd also want to make sure that the the importing from the modules in `Common` is bubbled up to the caller's module e.g so the `Dumper` function from `Data::Dumper` can be called without fully qualifying it (i.e it's been imported into the caller's package). Would each package get their own copy of $log with the correct package name? Again, because of lexical effects `$log` will not be visible in external modules. In this particular case you could either use a function such as `Common::log` to return a lexically scoped `$log` or just have a `$log` package variable e.g `$Common::log`. Search around for singleton objects for more information on the subject. HTH `_________ broquaint`	[reply]
Re: standard require by Abigail-II (Bishop) on Apr 23, 2003 at 10:11 UTC
That "trick" doesn't work for lexical scope pragmas like `strict` and `warnings`. You also want to be careful that the modules you are using export their symbols to the right package. I would not easily do something like this. If you want to save typing, use a template, and copy the template when you start with a new file. Or use an editor macro. Abigail	[reply] [d/l] [select]
Re: standard require by demerphq (Chancellor) on Apr 23, 2003 at 10:11 UTC
I wouldn't do this if I were you. If your modules are OO then inherit, otherwise just write yourself a module template that you can use in your editor. I say this because I think its much better to have all the dependencies listed in the same file. I also think that you might have module interactivity problems at a later date if you make chages to the "common" module that could be very difficult to track down. --- demerphq _{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...}	[reply] [d/l]
Re: standard require by zby (Vicar) on Apr 23, 2003 at 10:10 UTC
It seems like a good idea to me, I can't see any disadvantages. And I would use `use` not `require` - just because it's more common and convenient in other circumstances. Update At least it should work for the litany of `use` statements other than the pragmata.	[reply] [d/l] [select]
Re: standard require by nothingmuch (Priest) on Apr 23, 2003 at 14:44 UTC
What about stationaries? If your editor supports templating, maybe it's a better idea to use it? The problem with using something like that comes, lexical pragmas aside, at maintain time. If you change common to something else, and suddenly a different program breaks, then stuff goes bad. Or if someone else is trying to see what you did and how to change it, it might be confusing. I think it might be Bad Form™, but no more. If form is what concerns you than using idioms and standards is usually the best choice. -nuffin zz zZ Z Z #!perl	[reply]