using strict from another module

[Anonymous Monk]

Hi,

I would like to write a package for my own personal use and would like to include some common modules to cut down on typing. Basically things like use strict, warnings, carp etc. My problem is even though I have them in the module, my script dosnt pick up on them.

IE if my script contains the line

use mod::personal;
print "$test\n";

I would expect it to give me the following error: Global symbol "$test" requires explicit package name at C:\Perl\tester.pl line 2.

use strict and use warnings are the first 2 lines in the mod::personal module. Anyone got any ideas how I can do this?

Thanks in advance.
John

[Corion]

I don't advocate this solution, but there are two modules for that - ToolSet, which gives you an object/class based approach, and ToolKit by TheDamian, which gives you a magic approach. I haven't used either, and I fear that you'll get bitten by ETOOMUCHMAGIC if you use them instead of simple templates or cut'n'paste in your editor, but there they are.

[Anonymous Monk]

Thanks for the quick reply.

I wont be using this for magically including half the world, already been bitten by that by auto exporting functions from my module with similarily named ones in included modules(I'm now not auto exporting any functions). It's my first attempt at implementing a module.

Thanks again.
John

[xdg]

In addition to the Pod, I describe ToolSet briefly in Bundling commonly-used modules into a toolset. There's really very little magic involved.

[salva]

calling strict->import from your toolkit module import method will do:

package mod::personal;

require strict;
sub import {
  strict->import;
  ...
}

strict->import changes some bits on the $^H variable that is used internally by perl to control compilation.

[xdg]

This is exactly the approach used by ToolSet.

[Anonymous Monk]

Hi,
That works as you explained. The thing I don't understand is now I have to fully name my exported methods by using the package name,
IE instead of:
phash(\%hash)
I need to put:
Mod::Personal::phash(\%hash)

Any ideas why that is?

[xdg]

It's because you are no longer using Exporter's import. ToolSet takes care of this by doing the import for you, plus it will re-export functions from other modules -- which you'd also have to do in your custom import routine if you want to make, say, Carp functions available when Mod::Personal is used.

You're really just re-implementing ToolSet step-by-step. Here's how ToolSet would work:

package Mod::Personal;

use base 'ToolSet';
ToolSet->set_strict(1);
ToolSet->export(
  'Carp'        => undef,         # get the defaults for Carp
  'List::Util'  => 'shuffle sum', # or specific functions
);

our @Export = qw( phash );

sub phash {
  # your code here
}

1;

[salva]

The problem is that now, Exporter->import is not being called, because mod::personal->import is hidding it.

Calling Exporter->import from mod::personal->import would not work either because it expects to be called directly from the package where the subs have to be imported. Fortunately Exporter has another method just for those cases: export_to_level:

package mod::personal;

require strict;
require Exporter;
@ISA = qw(Exporter);
@EXPORT_OK = qw (phash);

use Foo qw(phash);

sub import {
  strict->import;
  $_[0]->export_to_level(1, @_);
}

[roboticus]

John--

I second Corion's sentiment: When you go to another machine and try to do a quickie, you may not have access to your personal module.

That said, I'd suggest creating a macro in your editor to plop in the important stuff. For example, if using vim, the command:

:abbrev ## #!/usr/bin/perl -w^V^Muse strict;

would insert a typical pair of lines at the start of your program when you enter ## in insert mode. Most editors have a similar macro feature. In fact, there have been several great threads about setting up editors for use with Perl. (I'd include some links here, but I'm still a newb, and don't know which ones are the best to include.)

--roboticus

[chromatic]

When you go to another machine, you may not have access to your personal macro!

[xdg]

I keep my .vimrc on my subversion server for exactly that reason. Of course, you could do the same with a personal module, too.

[roboticus]

chromatic--

Very true, ++ for you!

My original intent was that I think it's important to see the standard junk at the front, so you don't forget the basics. (Very important, especially for beginners...) If only I had thought to say so.

Thanks for the catch!

--roboticus