For example, in your brand new program that does the day's latest challenge (and perhaps you start with a virtual template of a script that you know functions vaguely similarly) you have something like:

require 'my_general_subs.pl';

my $var1 = shift;
my ( $var2 ) = mgs::get_data( $var1 );
[download]

Then, in a file named my_general_subs.pl that is in one of the @INC directories (thus allowing my_general_subs.pl to be in the current directory), you start with:

package mgs;
[download]

followed by subroutine after subroutine (i.e. no "main" stuff required in this library file, just cool subs that you want to reuse and maybe some initializing statements). Eventually, the file even contains the subroutine you are invoking as in:

sub get_data {
    my ( 
         $name,    # optional comment explaining @name
         $grade,   # optional comment for optional $grade
             ) = @_;

    my $answer;

# Do stuff with $name, $grade, concoct some kind of $answer
# ...

    return ( $answer );
}
[download]

Keeping to the general rule of one package statement per library file (i.e. files like 'my_general_subs.pl' as above), you create several of these library files to contain related subroutines. Suddenly, code reuse becomes a piece of cake! (Check out how to pass filehandles as parameters and also ways of redirecting STDERR to always point to the same file for more robustness here.)

As you are alluding, it's great to write code just once so that you aren't always rewriting the same old thing (also multiple-script maintenance is easier), but since Perl code is fairly easy to generate anew as necessary, you get the best of code reuse without being locked into a one-template-fits-all approach.

This is really brilliant. This is exactly what I am going to do. I only wish I could send more points.

--
ellem@optonline.net
There's more than one way to do it, but only some of them actually work.