in reply to Re^4: RFC: A YAML config module to be posted to CPAN
in thread RFC: A YAML config module to be posted to CPAN

You misunderstand me. You need one subclass per application, and one directory tree with all your config data.

Again, you're making assumptions that may make ense to you as the author and the user ... but if you want this to be generally reusable for other people (which is i'm assuming your reason for posting it as an RFC and ultimatley to CPAN) you have to acknowledge that not everyone wants to do this ... there are *lots* of good reasons why an application may want o use multiple unrelated directories to store configuration.

even if it turely is one per applcation, why should i rewrite the same 3 line module over and over for every application with the only difference being the directory name?

Is that really so difficult?

No, but it's cumbersome, and limiting -- not things that generally make a module reusable. Loading data only once at startup may make sense to you, but i may want to make it possible to reload my configs on demand ... i can't do that with your module as is. Loading the data in a way that makes it globally accessible may make sense in some applications, but in other applications it may make sense to have the config data more protected, and only pass it to the methods that need it.

For the use case you seem to want to make really easy (parse config files once on startup, make available globally) your approach 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... 

use Burro:Config;
$main::config = Burro::Config->parse('/my/conf/dir');

[download]

Two lines. Done. No custom subclass per config directory, no importing the custom subclass in all the other modules that need to know about the config -- every piece of code that you suggest needs to "use My::Config" before calling your C function can now just know to call $main::config->C instead.

Replies are listed 'Best First'.
Re^6: RFC: A YAML config module to be posted to CPAN
by clinton (Priest) on May 13, 2007 at 14:55 UTC
    ...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

[reply]
[d/l]

In Section Meditations