..it's not clear to me why you consider that an advantage. it's shorter there's no doubt, but there's a lot of information in the first case that's not in the second case: mainly an easy way to disambiguate between "i want the second item from the section named 'servers'" and "i want the section named '2' in the section named 'servers'"

The inspiration came from Template::Toolkit's way of dereferencing variables - it's clean, easy to read and, (imho) perfect for configuration. Assuming your YAML is correct, there will never be a confusion between 'the second item from the section named servers' and 'the section named 2'. The reason for this is that the value at 'dbconfig.servers' is either a scalar, a hash ref, or an array ref, so assuming it is not a scalar, it has to be one of the two - not ambiguous. My module doesn't do validate the underlying YAML - it assumes that you know what you're doing. In order to validate it, you could use Kwalify to check the data against a schema. I've been using this module for over a year, and it has never been an issue for me.

It would be helpful to know what types of error handling/messages does your mod produce when config values can't be found -- or when a value can be found, but it is not in the right context (ie: i ask for 'dbconfig.servers.2.host' but 'servers' is a hash, or 'host' is a single item ut i've asked for an array. (these are examples of the types of errors i'm worried about since you use your own string based lookup syntax instead of letting people rely on standard perl sigls and error messages.

In your example, the '2' could equally be the third element in an array, or a key called '2'. So the module doesn't differentiate between these. There is really only one error at data lookup time, and that is: "unknown key '2' at 'dbconfig.servers'". So the key either exists or it doesn't, and if it doesn't, it throws an exception. As I said above, this has never been a problem for me. I think, because you're working with configuration data, you generally know what it looks like before you run the program. It's not the same as (eg) parsing user submitted data from a website.

The use of singletons and the need to create a subclass seems obnoxious and unnecessary. if the goal is to let people both: 1) load a config set in one place, and refer to it from elsewhere in the code without passing an object refrence arround; 2) load multiple config sets; then instead of making them create a seperate package for each set, why not let them declare a global (or package) variable for each set and assuign an instance of your object to it. that way they can control the scoping...

Yes... I think I might have gone a bit overboard with the whole minimalism thing, when I was writing it. I wanted it to just work, be shared between mod_perl modules, and require the minimum work to get access to it.

In practice, it is really easy to use

• the only slight annoyance being that you have to create a file as follows:

  
    file:  My/Config.pm:
    --------------------
    package My::Config;
    use base 'Burro::Config';
    1;
  [download]

• Then you load the data once (eg for mod_perl, in startup.pl):

  
      File: startup.pl:
      -----------------
      
      use My::Config '/path/to/config/dir';
  [download]

• Then for any module that needs access to the config, you just add this to module file:

  
     File: My/Module.pm:
     -------------------
  
     use My::Config;
  
     $value = C('key1.key2.etc...');
  [download]

I fully admit that I'm doing some stuff in the import sub which may not be the best idea, I'd welcome feedback on that. But the fact is that it works, and it is easy to use and easy to maintain (eg when moving code around)

So I'm wondering if others would find it sufficiently useful for me to release it to CPAN?

Clint

PS Thanks for taking the time to read and respond - I realise it was a long loooong post.

---

---

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! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

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:
	&		&
	<		&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.