in reply to Re^13: My globals are visable; but undef'ed
in thread My globals are visable; but undef'ed

Don't trust rules of thumb for code smells too much. For example odds are that you need to write a lot of small utilities. Odds are that there is a lot of common code around things like loading up the libraries you're always using, processing command lines, etc. The usual solution is to have a template you always start with. However what do you do if the template needs fixing? (Eg a new version of some module looks at an environment variable that old ones had not, and so breaks taint checking.) Also the framework code can get to be quite lengthy - which means that when you open up a script you have to scroll down for the code. That is no good!

A very good way to solve this problem is to move that common code off into a library that sits in package main. For example you might have a small module called Configuration::Bootstrap that will figure out your appropriate paths to your codebase and configuration, then loads Configuration. And Configuration in turn will load your config files, set standard global variables, process your command line, copy command line variables into global variables and declare them, etc. The result? Your starting configuration will look like this:

#! /usr/bin/perl use strict; use warnings; use Configuration::Bootstrap ( "help" => 0, "man" => 0, "database=s" => undef, # ... ); use Company::Database; use Company::Person; # PROGRAM HERE __END__ =head1 NAME progname - Describe your program here ...
Sure, doing this means you have to have package main split across different files. It means that you have to use symbolic references. Etc, etc, etc. Lots of code smells.

But the smells are misleading you. This is actually a good thing to do, and it will make your codebase easier to work with. However when you do it, you'll see immediately why our would have been the wrong thing to do.

That said, this example notwithstanding, there aren't many cases where you want to split packages across files. However if you implement it, you'll find yourself using this one over and over again. :-)