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."