The project is composed of a series of Perl scripts, using Bash scripts as wrappers to call them and pass data between them.It's hard to comment on this specific use without actually seeing the bash scripts and understanding the rationale for their existence. In general though, I prefer to write it all in Perl and avoid writing bash scripts.
What puzzles me is two modules that seem to handle configuration information, called ParseConfig and DataConfig, respectively. They do not read in a configuration file, but instead are primarily a series of package variables (with some subroutines thrown in as well) that are then used throughout all of the scripts, loaded via a use statement at the top, then referred to via their full package name (ParseConfig::somevariablename).I would describe using package variables like this as vulgar and amateurish. More orthodox is to use a hash, as the Perl core Config and Net::Config modules do. Making the hash readonly is desirable because changing state in globals tends to make systems hard to maintain. Allowing the user various ways to override default configuration settings is also common; for example, Net::Config uses a .libnetrc file in the user's home directory.
Finally, in the interests of loose coupling and high cohesion, you should strive to make it clear which subset of these many configuration variables are actually used by each of your modules. A simple way to do that is to have a module take a hash of attributes in its constructor; the module itself uses those attributes only to get its work done and never peeks at the global package variables.
In reply to Re: Should you use a module to hold configuration items?
by eyepopslikeamosquito
in thread Should you use a module to hold configuration items?
by romandas
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |