... assuming it is "correct" is a bad assumption.

If somebody is editing the config file, they're probably changing something that you originally wrote. They are much more likely to get the values themselves wrong, rather than to change the type of a data structure. So obviously, if you're in this situation, you would need to validate the data before using it. Just as with any data from a suspect source. Fine. Being certain that it's a hash or an array will be nowhere near enough to be sure that you have good data coming in.

...I can't possibly imagine how you can consider that syntax unambiguous: you tell me, is "a.b.2.3" referring to $conf->{'a'}->{'b'}->{'2'}->{'3'} or $conf->{'a'}->{'b'}->[2]->[3]?

I'm not suggesting that we replace all references to variables in Perl with this, but for the kind of data that I need to use, this notation makes for very easy reading.

The typical use of lists of values in configuration data (in my experience), is that you want the whole list so that you can iterate through it. So you ask for the whole list: 


    @hostnames = C('db.servers.search');
    foreach my $hostname.... etc

[download]

So practically speaking, I do not find this confusing. I can't be so way out there - lots of Template::Toolkit users do exactly the same thing without complaining.

...having to create a seperate mini little perl module for each config dir i want to read from

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

I've been using this module for mod_perl applications, and there it makes sense to load all your data once at startup, so that the memory is shared between the child processes. I have all my config data in one directory tree. I have a single config module (which subclasses Burro::Config; for the entire application. I specify use MyApp::Config 'dir'; once in my application, and in every other module where I want to use it, I specify use MyApp::Config

Is that really so difficult?

UPDATE : That said, I realise that this is not the normal way that Perl modules work, and this is the part I have the most doubt about. It would be easy enough to change it to returning a config object which you could then pass around all of your modules. It pretty much does that already, behind the scenes. I just figured that this way was shorter and more convenient, but I concede that it may not fit into the way others like to do things.

Clint

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

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.