Dear Jamis,

Jamis Buck wrote:
> Copland (an IoC container for Ruby) is moving forward, and I *think* 
> it's almost ready to be considered at a "beta" level of stability and 
> usability. That said, I need feedback: is anyone here using Copland? 
> I've heard from (I think) two people, off list, that are using it.
> 
> What I need is (a) what features you feel are still missing, and (b) 
> what features you think need to be fixed.

I am new to the IoC/DI kind of working, but I find it _very_ 
interesting, although I don't actually know how to get started. The 
documentation is very good so far, but only covers the basics and it 
doesn't help with "getting into it" (me at least). The reason I can't 
decide to use this technique is because there are no real world examples 
I could look at (for Copland, I guess there are for Java DI libraries). 
It really bothered me when, after enjoying the whole very nicely written 
documentation, I still didn't know how exactly I could use Copland to 
help in my programming. What I am saying is that I would really like 
some small example app which shows the difference between using Copland 
and not using it. Some good instructions. I am not asking you to write a 
book, but maybe you have read Kent Becks Test Driven Development or "A 
Programming Episode" in Agile Software Development by Robert C. Martin. 
I would like to have some advice on "Here is how you use it".

"Ask not what I could do for Copland, ask what Copland can do for me" ;)

If it not asking too much I would really like to see 2 little sample 
apps with the one where you could at least start to see the benefits in 
action. I understand that the real benefits start to show when the 
system is getting bigger. I would need something that would bring me 
into the right mindset so I could decide to use this technique for my 
programming efforts or when to use it. Does that make sense?

Using DI seems to me like a little more than just using the next 
library. Maybe it is not such a big paradigm as TDD, but it seems like a 
certain way of programming that needs a little more explanation than the 
usual stuff. I really wonder how I could benefit from that.

-- 
Sascha Ebach