I still don't think that Copland is in any way useful to me (I just
simply don't have large trees of dependencies within a single process,
and where I do have dependencies, I handle it by instantiating all my
objects before the main loop; objects that depend on other objects
require them as parameters to their constructor).
That said, Copland does looks pretty clean and well-documented, and I
like the idea of making it even cleaner by eliminating the YAML file.
I've thought a lot about a library for the declarative syntax that you
and Nathaniel mentioned. I've written such a library, but it's
unfortunately not nearly as clean as I would like:
http://rubystuff.org/scriptable_config/scriptable_config.rb.html
It's used like this:
module MyConfigurationTemplate
extend ScriptableConfig::Template
Template = {
:host => Option(),
:port => Option(),
:plugin => SectionTable ({
:id => Option(RequireType(Numeric)),
:file => Option(RequireType(String))
})
}
end
c = Config.new(MyConfigurationTemplate::Template)
c.read_file("config.rb")
c.validate()
Then the configuration file (config.rb) can look like this:
host "foo.com"
port 42
plugin('spam filter') {
id 1
file 'antispam.rb'
}
plugin('keepalive monitor') {
id 2
file 'keepalive.rb'
}
and produces a nested hash table with the specified configuration. I
never bothered to release the library because 1) when I asked about it on
irc, I was told that I was crazy and that I should use XML for this and
2) it still seems a bit klunky to use (though I am using it in
production -- it's been really valuable in a pinch to have the
configuration file be a ruby script, as this allows pieces of the
configuration file to be generated through connections to a database or
through reading an external config file, all without changing any of the
source code. it's a two-edged sword, though; reading configuration
files generally shouldn't have side effects, and this solution allows
them).
Anyway, it would be really cool if you could take this concept one step
further with Copland and make it even less verbose and more generically
useful. I'm not entirely sure what that would look like, as I am
somewhat limited by what I've already created (as David discussed in his
Rails talk).
Paul