From what I understand of Copeland, it's not really that useful to the
first developer - or better said, to the first time something is
developed since þåre needs to be a lot of 'extra' work done - but it
pays off later...

When you or another coder goes back to that project and wants to use
something that was previously coded that it would be _very_ useful,
since with minimal changes you could substitue one part of your code
for a different, or better part.

Say I wrote something that used 10 parts. I left it for a while, and
later came back because I knew I could rewrite part #4 better. I
wouldn't have to mess with parts 1-3, or parts 5-10. Just make sure
part 4 quacks like the duck that it used to be and change a few lines
in Copeland and you're in business.

-Rich




On Wed, 6 Oct 2004 02:45:19 +0900, Paul Brannan <pbrannan / atdesk.com> wrote:
> 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
> 
>