in reply to AppConfig variables and OO

If all your package is going to do is hold a single blessed reference to a hash, creating a special OO configuration package seems like an overhead inefficiency, both in terms of programming and execution. However, if the rest of your program uses OO design, you may want to. Instead of building a single config var get() method for each var, you might consider a permutation on the AUTOLOADER idea that allows you to specify a list of keys, and returns the values in that order. You might also consider not having a new() constructor to prevent polymorphous instances of configuration, and then write all methods as class methods.

I haven't been impressed (on very cursory inspection) with what I've seen for config modules on CPAN yet, so please write a review if you use one and get a decent understanding of its strengths and weaknesses.

update: on reviewing AppConfig, it sure looks like a robust module, worth the time to learn to use if you have more than trival configuration concerns.

Replies are listed 'Best First'.
Re: Re: AppConfig variables and OO
by BoredByPolitics (Scribe) on Jan 10, 2001 at 22:57 UTC

    Thanks for your reply - I've done some reading up of OO with Perl over the last 24 hrs, and have come to the conclusion that I'd best stick to traditional methods until I understand it a little more.

    Regarding AppConfig; I agree with your conclusions, although the only problem I've encountered so far is with the AppConfig::State VALIDATE option. If a parameter fails the validation, with PEDANTIC set to 0, the $config->args() method doesn't let you know what happened... as far as my testing shows.

    Other than that, it's a very useful module.

    Pete