- was the library's design flexible enough? If not, how would you suggest it should be redesigned to broaden its scope of use?
Very promising looking library. I think we've all had to roll some sort of config parser in the past, so there is a lot of potential for this to gain widespread adoption if its functionality exceeds home-grown versions. Two things that I had to roll into my config system: a) ability to include other files b) inline variable expansion, e.g. site.root = c:\dev site.home = ${site.root}\home The former is important for me as I'll often have a lot of common configuration files shared between products, but I don't want client code having to care about opening half a dozen conf files to find a particular setting. Instead, client code opens '<productname>.conf', and that file happens to 'include(...)' all the other config files necessary, The latter is very Java-.properties-esque, but I don't see any reason why it couldn't be used here. It's extremely flexible, especially if you leave evaluation of inline properties to the very last minute, such that you can consult the entire property tree for the corresponding value (rather than expanding the value as soon as you come into contact with it, restricting you to reference values that have been defined before your reference occurs). What are your thoughts on this being included in your library? Anyone else need to do this type of stuff, or would find this useful? Trent. -- http://www.onresolve.com