Re: strict, debug and global variables

You can create a package with package global variables in it, and get at those variables using their fully-qualified name, like this:

First, just name this one MyConfig.pm:

package MyConfig;

use strict;
use warnings;

our $testvar = "Hello world.";

1;
[download]

And now in MyScript.pl:

#!/usr/bin/perl

use strict;
use warnings;
use MyConfig;

print $MyConfig::testvar, "\n";
[download]

Using the fully qualified variable name means you won't be exporting it directly into your main script's namespace, you'll just be accessing the configuration package's namespace. That's a pretty easy way to do it.

Dave

Comment on Re: strict, debug and global variables Select or Download Code

Replies are listed 'Best First'.
Re^2: strict, debug and global variables by Aristotle (Chancellor) on Sep 17, 2004 at 00:09 UTC
The drawback to fully qualified names is, of course, that you don't get the typo checking otherwise offered by strict. Makeshifts last the longest.	[reply]
Re^3: strict, debug and global variables by davido (Cardinal) on Sep 17, 2004 at 00:51 UTC
Pick your poison I guess. There are a lot of ways to deal with configuration data. The OP seems to want globals, and I figured at least with fully qualified variables at least he eliminates namespace pollution. There are many many other alternatives too though: Config::General which grabs configuration data from a file and plops it into a hash. I happen to like the hash approach, though to your strict point, a hash's elements also are not subject to the helping hand of strictures. Using a package and accessing its configuration variables via their fully qualified names. It doesn't pollute package main's namespace, but also doesn't result in the strictures checking. Exporting from a configuration module / importing into the main script. While this will benefit from the `use strict;` assistance, it will also pollute package main's namespace. If you don't have absolute control over the configuration file, it would be easy to inject trouble this way. Use Data::Dumper, or Storable to read in the configuration information. Put the configuration information into a package, and export a set of accessor funtions to get at the configuration info. That way you're not actually touching the configuration variables, but accessing their data through sanitized accessors. A well behaved accessor should react appropriately when the caller tries to access configuration data that isn't part of the package. A config object... This method could automate reading the data in from some source, and provide methods for retrieving the data. ...similar to the previously-mentioned proposal, but has the potential of creating a simpler interface through the magic of Object Oriented abstraction. And about a million other approaches, some better than others. ;) Dave	[reply] [d/l]