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

What I'm wondering is whether this is considered good Perl coding practice?

I think you're asking the wrong question. You should consider asking (yourself) the following:

Does it work?
Given this is an existing project, I'm gonna assume the answer is yes.
So then you have to ask yourself: what are the risks involved with changing it?
Is it difficult to maintain?
Reading between the lines of your description, I'm gonna assume the answer is no.
If you need to change the value of an existing configuration parameter, you go into the .pm file and edit it.
If you need to add a new one, you edit the .pm file and add it.
That doesn't sound particularly hard to me. In fact, it sounds identical to the process of maintaining a configuration file in some other format--say YAML.
But--and here is the crux of my argument--when you've made changes, validation is as simple as:
```
perl -c configModule.pm
[download]
```
And if the editor forgets to validate, the error will be detected immediately at program startup, as a Perl syntax error, with the clarity of Perl's syntax error messages.
Ask yourself:
How good are the the equivalent error messages for your prospective config file alternative?
How good is the beta test cycle of your prospective config file format parser (say YAML), compared to that of Perl parser itself?

Many will condemn the existing mechanism as "crude". But crude is often a euphemism for 'simple'. And there is very little wrong with simple.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re: Should you use a module to hold configuration items? Download Code

Replies are listed 'Best First'.
Re^2: Should you use a module to hold configuration items? by TomDLux (Vicar) on Sep 19, 2010 at 05:05 UTC
Changing a module is not always trivial. Where I work it involves creating a document requesting permission for a change, a process which normally takes a week or two. Of course there are emergency requests you can process without outside discussion, to handle things that break at 2 am, but the discussion of why it was needed simply follows the change rather than precedes it. Then you have to unlock the source project, check out the file, change it, check it in, and distribute the changes to the production file system. As Occam said: Entia non sunt multiplicanda praeter necessitatem.	[reply]
Re^3: Should you use a module to hold configuration items? by BrowserUk (Patriarch) on Sep 19, 2010 at 09:51 UTC
If you have configuration files, that drive the actions and correctness of your applications, that are subject to less strict procedures than your source files, you have a gaping hole in your process.	[reply]
Re^3: Should you use a module to hold configuration items? by Jenda (Abbot) on Sep 19, 2010 at 09:13 UTC
The important question is ... is changing a config file in a different format any easier? Jenda Enoch was right! Enjoy the last years of Rome.	[reply]