Introducing Class::ConfigHash
A while ago I saw a post by Ovid on boxing hashes for configuration in Dancer. The idea seemed pretty neat, and I found myself doing something similar in some work for Net-A-Porter, so I wrote a generalized implementation (although the underlying mechanism is different). From the synopsis:
my $config = Class::ConfigHash->_new({
database => {
user => 'rodion',
pass => 'bonaparte',
options => {
city => 'St Petersburg'
},
},
});
$config->database->options->city; # St Petersburg
# Dies: Can't find 'flags' at [/->database]. Options: [options; pass; user]
$config->database->flags;
# Won't die, returns undef
$config->database->flags({ allow_undef => 1 });
# Won't die, returns 'foo'
$config->database->flags({ default => 'foo' });
# Access the underlying structure
$config->database({ raw => 1 })->{'user'} = 'raskolnikov';
You can see the module itself here: Class::ConfigHash
I blog about Perl.
Similar module: Data::Hive.
It would be cool if you could explain the differences between your new module and Ovid's implementation for Dancer.
Congrats on the module! :)
There are a few differences, but the most interesting to the end user is probably that Class::ConfigHash doesn't rely on having Dancer installed ;-)
From a feature perspective, Class::ConfigHash allows you to have default values, or specify that certain paths are allowed to be missing.
From an implementation perspective, Class::ConfigHash relies entirely on AUTOLOAD, rather than adding methods. This means it doesn't do an upfront conversion in to an object, instead resolving values as paths are called. My understanding is that this may make the Dancer version potentially a little faster at the cost of more loading upfront, but also unable to handle the config hash changing.
So Dancer::Config::Object is also faster, assuming your config hash won't change once loaded.
Peter, thank you for taking the time to explain the differences to me. :)