On Wed, Mar 25, 2009 at 00:03, Chap Harrison <c...@pobox.com> wrote:
> Hi again,
>
> I'm trying to factor out the declaration and setting of a bunch of variables
> that a suite of programs will need, as well as defining some subroutines
> that will be needed.  I've been mainly referencing Programming Perl 5, but I
> am mighty confused at this point.
>
> I'm particularly confused about how variables that are declared in my
> Package manage to become visible to main (although that's exactly what I
> want to happen).  As well as the whole issue of what happens when (at BEGIN,
> at use, etc.).  I feel sure I've greatly complicated things; as I say, all I
> want is a way to initialize a handful of "global" variables, and provide a
> few subroutines.

You need to add the variables you want exported to either @EXPORT (the
mandatory list of things to export) or @EXPORT_OK (this list of things
to export on demand).  The biggest complication is your desire to pass
in a variable.  This means that we cannot use the import function that
Exporter creates for us (since it doesn't know how to use $g_project).
So, we have to write our own import function and call export_to_level
ourselves.

---- testmod.pl ----

#!/usr/bin/perl

use strict;
use warnings;
use lib $ENV{LMI_DEVELOP_PATH}; #FIXME: maybe this should be set in PERL5LIB?

my $g_project;
BEGIN {
    #get project from the command line before Dummy is loaded
    $g_project = "VA-Orange"; #DEBUG
    #FIXME: need to do commandline parsing here
}

use Dummy $g_project; #exports $g_database_path
use File::Basename;

my $program = basename $0;

print "Hello from $program.main\n",
    "the database path is $g_database_path\n",
    "And now, goodby from $program\n";

---- Dummy.pm ----

package Dummy;

use strict;
use warnings;

use Exporter;
use Carp;

our @ISA     = qw/Exporter/;
our $VERSION = "0.0.1";

#list of the variables/functions to always export
our @EXPORT  = qw/$g_database_path/;

#list of the variables/functions to export if the user asks for them
our @EXPORT_OK;

#list of tags that bring in groups of functions/variables for lazy users
our %EXPORT_TAGS;

#This is where we should put the global variables, they need to
#be package variables, so they are declared with our instead of
#my
our $g_database_path;

#any initilization that doesn't need arguments from the module
#should go here

#DEBUG:
print "Hello from Dummy.BEGIN\n";

#--- S U B R O U T I N E S

sub usage {
    return 'usage: use Dummy "projectname";';
}

#we are replacing the default Exporter::import with our own
#so we can do accept the project as an argument to the loading
#of the module, this means we need to call export_to_level ourselves
sub import {
    croak usage() unless @_ > 1;
    my $pkg       = shift; #the name of the package, passed by use
    my $g_project = shift;

    #DEBUG:
    print "Hello from Dummy::import() - looks like project='$g_project'\n";

    my $gk_env_databases_path = "LMI_DATABASE_PATH";

    #DEBUG: fixup env. for purposes of test
    $ENV{$gk_env_databases_path} = "$ENV{HOME}/%s";

    my $g_all_databases_path = $ENV{$gk_env_databases_path};

    #croak causes the error to appear at the point the function was
    #called instead of at the point you die
    unless (defined $g_all_databases_path) {
        die "Environment variable '$gk_env_databases_path' is not set.  ",
            "Need to run lmi-admin.\n"
    }

    lop($g_all_databases_path);

    $g_database_path = sprintf $g_all_databases_path, $g_project;

    #_ is the last file stat'ed, so these are nearly free additional
    #checks to see if it is a directory and that the directory is
    #readable
    unless (-e $g_database_path and -d _ and -r _) {
        die "The district database, $g_database_path, does not exist.\n",
            "Did you specify the project name correctly? ($g_project)\n",
            "\nExiting.\n\n";
    }

    #export everything in @EXPORT, and everything in @EXPORT_OK
    #that was passed after the project name
    $pkg->export_to_level(1, $pkg, @_);
}

sub lop {
   $_[0] =~ s{/+$}{};   # lop off any trailing slashes
   return;
}

1;                              # Succeeded in loading module

-- 
Chas. Owens
wonkden.net
The most important skill a programmer can have is the ability to read.

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/


Reply via email to