Re^2: strict, debug and global variables

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]