I agree. In fact I think a better solution would be not to have Perl code in the config file but name/value pairs and read them into a hash.
Perhaps even better use a CPAN module for the config file handling. | [reply] [Watch: Dir/Any] |
I disagree.
There are plenty of legitimate reasons to want to have
more complex data structures in a configuration than
just a simple hash.
Also while there are plenty of configuration modules on
CPAN, I haven't seen any that I like very much. Here are
the main capabilities that I want out of a configuration
solution:
- Be able to have any kind of data structure into
the configuration.
- Be able to have a search path with selective
overriding of configuration information. For instance
the development and production configurations should be
as similar as possible, with only a few key values being
overridden.
- Be able to selectively tie together the
configurations of separate modules which should share some
common information based on your environment.
- Have checks so that if someone is trying to access
a variable from the configuration that isn't there, you
can catch it and fix.
On these criteria, most of the CPAN configuration modules
score 0/4. Just using raw Perl as a configuration file
scores 2/4. A simple bit of code that searches a
configuration path and does every file it finds there
with a specific name scores 3/4. And if you know what
you are doing, it is possible to create a simple
configuration module that adds the export checks.
Now those wants are not everyone's. Everyone wants to
get different things from a configuration module (which is
one reason why there are so many configuration modules out
there). But I claim that my list is not an unreasonable
set of wants for a Perl programmer to have, and if you
have them then pure Perl is a perfectly reasonable kind of
configuration file to use.
| [reply] [Watch: Dir/Any] |