so I decided to print up all the information I could Google and find in here (which wasn't very much, mind you)

• Tutorials
  • Writing, Installing, and Using Modules
    • Simple Module Tutorial
  • Getting Started with Perl
    • Where and how to start learning Perl
      • Complete books online:
        
        • Beginning Perl by Simon Cozens, Peter Wainwright
          • chapter on modules
        • MacPerl: Power and Ease by Vicky Brown and Chris Nandor
          • chapter on modules

E:\> perldoc perltoc |grep module
            processes and process groups, Keywords related to perl mod
+ules,
            -I*directory*, -l[*octnum*], -m[-]*module*, -M[-]*module*,
            -M[-]*'module ...'*, -[mM][-]*module=arg[,arg]...*, -n, -p
+, -P,
  perlmod - Perl modules (packages and symbol tables)
  perlmodlib - constructing new Perl modules and finding existing ones
            module (sometimes unnecessary), INSTALL the module
  perlnewmod - preparing a new module for distribution
        What should I make into a module?
...
[download]

The only difference between a package and a module is the extension of .pm and and the module requires the package name? Is that right?

From man perlmod:

       Packages

       Perl provides a mechanism for alternative namespaces to
       protect packages from stomping on each other's variables.
       In fact, there's really no such thing as a global variable
       in Perl.  The package statement declares the compilation
       unit as being in the given namespace.  The scope of the
       package declaration is from the declaration itself through
       the end of the enclosing block, "eval", or file, whichever
       comes first (the same scope as the my() and local() opera­
       tors).

       ...

       Perl Modules

       A module is just a set of related functions in a library
       file, i.e., a Perl package with the same name as the file.
       It is specifically designed to be reusable by other mod­
       ules or programs.  It may do this by providing a mechanism
       for exporting some of its symbols into the symbol table of
       any package using it, or it may function as a class defi­
       nition and make its semantics available implicitly through
       method calls on the class and its objects, without explic­
       itly exporting anything.  Or it can do a little of both.
[download]

Now comes down to the theory behind using modules.. I know there is a difference between use and require, but when it comes to using variables inside the module should we be using $_ or @_ more often than predefined names? Or how does our data imported from our script into the module if it requires specific names? (note: I know some modules have their own variables to use).

You may want to read some manual pages.

Abigail

Failing that, I recommend you read perlnewmod. It has answers to a number of your questions and pointers to the answers to the rest.

-sam

Just say: *shameless plug* and we won't downvote you ;-)

A module _could_ be defined as a perl code file with a .pm extension that contains one or more package declarations

And a package _could_ be defined as a concept where code, declarations, subroutines, methods and documentation relating to a specific implementation are collected

Note that if we use these definitions, a package can span several modules (files with .pm extensions)

So lets consider just single .pm file that completely contains one package (declared with the package keyword)

So for package Foo::Bar, I need look for a file Foo/Bar.pm, which starts (in general) with the declaration

package Foo::Bar;
[download]

With that in place, you question about use and require, use is (generally) the same as

BEGIN {require Foo::Bar; Foo::Bar->import();}
[download]

In general, you'll make use of require (no pun) when dynamically pulling in modules i.e. you dont know until runtime which module is required (again no pun) until after compilation.

As for @_, I use this, but I am using Params::Validate a lot now and passing hashes so I have named argument lists e.g.

my $baz = Foo::Bar->new(easy      => 'to',
                        see       => 'whats',
                        happening => 'here');
[download]

which means no more remembering the positional significance of arguments - its almost self documenting

For data 'from your script' to the module, try not to call out to a scripts data from a module - it reduces the reusability of that module, as every script must be written with that data in place if it wants to use the services of the module.

So dont do this

package Dark::Madness;

my $inner_demon = $main::higher_demon;
...
1;
[download]

Try to pass data back and forth through the interface - e.g.

$foobar->set_widget(param1 => value1,
                     param2 => value2,
                     );

$foobar->use_widget();

my $widget_dreams = $foobar->get_dreams(style => 'psychotic');
[download]

There are lots of consideration on the use of @EXPORT, @EXPORT_OK and %EXPORT_TAGS you should read up on, but basically try to use these as little as possible - they can be useful, but some people get upset when a symbol they have named gets clobbered by a symbol of the same name that is rudely exported by a modules @EXPORT list.

Arjen

Library? They probably have it.

I was going to complain that your library is obviously better than mine. But then I actually did a search and found that even my relatively small public library system has a large number of books on Perl. While they didn't have this specific book, they could most likely order it from a nearby college's library.

The lesson here is not only that we often forget libraries are a great source of free books, but that you should never assume your library can't get you the books you want.

---

Once it's Turing complete, everything else is just syntactic sugar.