Sascha Ebach wrote:
> Hi Jamis,
> 
>> Lots of sense. As I said in my reply to Hal, though, IoC really 
>> benefits large applications more than small ones. However, the 0.6.0 
>> release of Copland has a "real world" example application of a 
>> Calculator implemented using IoC. (I put "real world" in quotes, 
>> because although it demonstrates the techniques of programming with 
>> IoC, it's not the way you'd really want to do a trivial calculator 
>> program.)
> 
> 
> Ah, I stumbled upon this, but when I got through with the docs I forgot 
> about it. Maybe you could put a sentence at the bottom of each example 
> like: "For a small example program implemented with IoC see the examples 
> dear of the distribution" or similiar. Will have a look at it.

Good suggestion -- I'll do that.


>> Still--I'll see if I can't think of a nice, large, "real world" 
>> example of IoC (specifically, using Copland) and then see if I can 
>> find a good way to present it in the documentation. Ironically, I 
>> don't have any large examples using Copland, although I've got a 
>> couple in mind that I keep intending to start "as soon as I'm done 
>> with Copland." ;)
> 
> 
> The thing with building frameworks not alongside a real application is 
> that you usually rewrite the whole thing alot (ring a bell? ;). 
> Shouldn't the framework be built around / from a real world application 
> just like DHH did with Basecamp and Rails? At least that is the advice I 
> always read about in books of well known authors ;)

I knew someone would try to call me on that. ;) What is actually 
happening is this: I use the HiveMind IoC container at work (for Java), 
and have really found it powerful and useful. I found myself wishing 
there was something like it for Ruby... and so Copland was born. There 
are a few applications I want to write, but haven't had the time yet, 
and I wanted to do them in Ruby using IoC. I may not have actually used 
Copland for anything yet, but Copland is a not-quite-clone of HiveMind, 
and I *have* been using HiveMind, extensively. :)

> 
> You wouldn't have to actually implement a complete large application. 
> But I suspect you could easily get to a point where you could say: "See, 
> if I do this the traditional way I end up writing 10000 lines of code 
> for 100 services/adapters, with Copland it only takes me 2000 lines of 
> YAML and 1000 lines of Ruby." Now this would be an argument for me to 
> "buy in".

A very good point. What you're looking for, then, are testimonials of 
some sort, even they were coming from me directly. Hopefully, now that 
I'm feeling more confident in Copland's stability and basic feature set, 
I'll be starting on some of my UFO's ("unfinished objects", from 
knitting terminology). Once those are working reasonably, I can probably 
oblige you and others with a few testimonials and comparisons.

> 
>>> 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.
>>>
>>
>> Thanks for the feedback, Sascha. I'll do some thinking, too. I'll see 
>> if I can find a better way to present IoC.
> 
> 
> This might sound funny, but I think you would have to sell the idea 
> more. Like TDD is sold by saying that
> 
> - overall development is faster, less debugging, you know when you are 
> ready
> - more confidence in the code
> - higher quality of code
> - ...

Doesn't sound funny at all, actually. I think you're absolutely right. 
I've tried to do some of that in the manual, but the attempt obviously 
missed. I'll see if I can compose a nice, concise, bulleted list of 
benefits that IoC provides.

> 
> What is the main reason for using DI? Is it to produce the same 
> functionality with less lines of code? Which is always excellent. In the 
> example you say that "unit testing is beyond the scope of this 
> tutorial." This actually disappointed me cause I hoped to understand it 
> better if I would see some tests. Wouldn't this be just another 
> paragraph or two (writing 1 or 2 test classes)? Or maybe you plan to do 
> a complete example about the way you unit test IoC containers 
> (environments)? Testing is using ...

Well, unit testing was beyond the scope of _that_ tutorial. I do plan on 
having a tutorial or example that shows how unit testing is made more 
possible (not necessarily easier) by using an IoC framework. I'm stuck 
in a tough spot, though--write documentation, or mature the framework? 
Both are equally important, and I've tried to strike a balance. More 
documentation is always pending. :)

> 
> I am looking forward to seeing Copland evolve and hope that I can get 
> around using it soon.
> 

Me too! Thanks very (very!) much for the feedback, Sascha. I can tell 
you've thought about this.

-- 
Jamis Buck
jgb3 / email.byu.edu
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."