At 01:51 PM 5/22/01 -0700, Paul wrote:
>--- [EMAIL PROTECTED] wrote:
> > To keep the code as modular and managable as possible I would prefer
> > not to define all the routines in the main script.
> > It seems like using 'require' is the way to go (since I don't have
> > the time or experience to do modules at the moment).
>
>Modules are actually pretty easy.
>Try it: make a file in the same directory as a test script. Call it
>abc.pm, and paste in this:
>
>   package abc; # this declares the namespace for the module
>
>   sub argtest { print "recieved: ", join(';', @_),"\n"; }
>
>   1; # always add this at the end of a module
>
>
>now make test script tst.pl:
>
>   use abc;
>   abc::argtest(1..3);

It's always seemed to me that the 'approved' way of creating modules to 
import routines into another script was a bit wordy.  In a nutshell, you 
have to do something like

         package abc;
         use Exporter;
         @ISA = qw(Exporter);
         @EXPORT = qw(foo bar baz);
         @EXPORT_OK = qw(blech flurble);

         sub foo { ... }

And that's not even with proper strictness enabled.

Now there are lots of advantages to this approach - ability to use private 
package variables, hide subroutines from the caller, allow them to 
selectively import symbols, etc.  But there's a lot to learn in there for 
someone who just wants to abstract some common routines into one place, 
which someone who'd only been learning Perl for a week might want to 
do.  So I'd suggest that someone wanting to do that, if they don't yet know 
how to use the Exporter and other terminology above, just stick the 
routines into a file and require them, subject to the following caveats:

Don't declare any package variables in the file unless they're constants 
you want visible to the main script.
Declare lexical variables all you want, they'll remain private.
You won't have any 'private' subroutines in that file.  That'll have to be 
okay.

Just bear in mind that there's a whole new world of wonderful stuff behind 
door #2 when you're ready for it.
--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com

Reply via email to