Re: Should you use a module to hold configuration items?

Some projects do use “executable code” to hold configuration data. (Sometimes, the modules are programmatically generated.) My wisdom is, “if it works now, don’t change it now.” Pick you battles carefully, like a good triage nurse at an E.R. You might not like the way it was done, but it does not appear to be screaming in pain...

TMTOWTDI... and only two that count: the one that works, and the other one that also works.

Replies are listed 'Best First'.
Re^2: Should you use a module to hold configuration items? by Anonymous Monk on Sep 20, 2010 at 14:09 UTC
You could, cautiously, say that such a design is “elegant,” if the design that you are stuck with is that “there are a bunch of separate scripts.” (Whether or not you think that having “there are a bunch of separate scripts” qualifies as “elegant” is beside the point.) All of the configuration options become available with one simple `use` statement. No separate parsing is required: the `.pm` file is the configuration file. If the options, once set, almost never ever change, that works.	[reply]

Replies are listed 'Best First'.

Re^2: Should you use a module to hold configuration items?
by Anonymous Monk on Sep 20, 2010 at 14:09 UTC

You could, cautiously, say that such a design is “elegant,” if the design that you are stuck with is that “there are a bunch of separate scripts.” (Whether or not you think that having “there are a bunch of separate scripts” qualifies as “elegant” is beside the point.) All of the configuration options become available with one simple use statement. No separate parsing is required: the .pm file is the configuration file. If the options, once set, almost never ever change, that works.

[reply]