Re^2: Application-wide configuration

Subclassing is there so that the modules are slightly more reusable (I use this Config::Once in several applications; don't want to pollute it).

If we don't need that, we can also drop no strict 'refs' and just do

use strict;
use warnings;

package Config::Once;

use Config::Auto;

our $Config;

sub init {
        my ($class, $config_path) = @_;
        ...
}

sub cfg {
        my ($class, $param) = @_;
        return $Config->{$param} if (defined $param);
        return $Config;
}

1;
[download]

And the ref was reflectory. Most probably not needed.

That's not to the point, though.

Comment on Re^2: Application-wide configuration Select or Download Code

Replies are listed 'Best First'.
Re^3: Application-wide configuration by ikegami (Patriarch) on Jul 27, 2007 at 19:04 UTC
The only think I can see subclassing be useful for is if you have to deal with more than one configuration file per application. I read the problem as needing to have a single config file shared by many modules. Reusability is not affected. Any other application that needs to have a single config file shared by many modules can reuse this module.	[reply]
Re^4: Application-wide configuration by akho (Hermit) on Jul 27, 2007 at 19:24 UTC
People have different approaches. But I meant a situation like this: I have two applications, each of them uses a database. Database name and other credentials are stated in separate configuration files. So, each of their configuration files contains a parameter named 'database'. If I later want to reuse ORM classes from both applications in a new application, I will not be able to do this if they use the same Config::Once class. (I will necessarily have several configuration files too, of course). That's what I meant by 'reusability'. This is probably ugly, but such thing happen. There may also be problems with separate web applications running under mod_perl (won't they share the same perl process and the same Config::Once, too?), though I may be mistaken. So I think simply using Config::Once everywhere is slightly easier, but may turn out to be a problem in some corner cases. Subclassing is a better practice. This is not very different from, say, common practice using Rose::DB.	[reply]