...actually seems like requires the application writer to write a lot more code then if you just returned an object and letting them assign to a global variable...

Do you know, I think I may agree with you. In mod_perl, people tend to preach against globals, because of the number of people trying to convert their CGI to run under mod_perl. But of course, there are times when it makes sense to use a global.

I remember now, the other reason I wanted to import a sub rather than using an object directly was for more conciseness, as in:

    @hostnames = C('db.servers');

  as opposed to:

    @hostnames = $c->C('db.servers');
[download]

... not much of a difference, I'd agree, but at the time, I was trying to get it as small as possible.

It suits me to use it this way (ie the subclassing), but I can imagine more people than yourself experiencing the same objections. It wouldn't take much for me to change it to be able to work in either way, as the user desires.

So given that change, would you recommend that I release this module? And if so, called what? There is an old module of mine called Config::Loader which I doubt anyone has ever used - would this be a reasonable name? It doesn't mention the YAML, but that may be no bad thing, in case I want to add the ability to read other types of data.

thoughts?

thanks clint