From: Rob Lally Date: 2005-04-14T16:22:16+09:00 Subject: Re: Needle and Parameterized Services Jamis Buck wrote: > On Apr 13, 2005, at 2:19 PM, Rob Lally wrote: >> At the moment I'm wrapping this block under the cover with another block >> >> def register_statement(name, &statement) >> @registry.statements.register(name, :model => :prototype) {|c, >> p, *args| statement.call(*args) } >> end >> >> Which works fine but feels a bit off. >> > > Ah, I understand now. Yah, currently there is no option to prevent those > parameters, so wrapping it as you did above is about your only option. I > don't know how I feel about adding an option to "turn off" the c/p > parameters. I know DI isn't a hugely popular approach in the Ruby world, > but...anyone out there have an opinion on this matter? Personally, I > think I'd lean towards just having consumers of Needle use adapters of > one kind or another to change the interface, as you did above. It's an > honorable and tried design pattern. > > What about it "feels a bit off" to you? Maybe that would help change my > opinion. :) I'm not exactly sure what makes me uncomfortable about it. I think that it is the lack of symmetry; if you want 0 parameters you define 0 parameters, if you want n you define n + 2. I think that at the moment DI isn't very popular in the Ruby world for a couple of reasons: 1) People are writing relatively small applications. DI becomes more important on larger code bases with multiple developers; amongst other things the physical decoupling makes it easier to perform the mental decoupling needed to concentrate on the corner of the code base you're working on. More and more people seem to be working collaboratively on Rails based projects so I would expect DI and needle to become more important here. 2) The dynamic nature of Ruby means it isn't as hard to 'roll your own' DI solution. If Needle got some more publicity I reckon people would use it more. One of the things I noticed on another thread about performance of unit test was a discussion of combinatoric complexity in unit tests. The posters solution was to spin of chunks of code into modules, a not unreasonable solution. Another alternative would be to use DI to rid the units under test of direct dependencies and eliminate the combinatoric explosion. Something I would like to see would be integration of Needle into Rails. I seem to recall quite a few threads on the Rails list along the lines of 'How do I make something available to all of my controllers'? The answer normally involves inheritance of environment.rb. If ActionController::Base had a registry associated with it or even if there was a (heaven forfend) global rails registry it would provide a single definitive place to put these kind of services. Rails itself could provide ActionMail, Logging or other services via this registry as well. IMHO dependency injection is a good thing and Needle is an excellent example of a DI framework. With lots of non OO developers coming in to Ruby via Rails it would be an excellent opportunity to spread the word about a valuable and powerful technique. I know that Rails values convention over configuration ... but sometimes configuration is necessary. When is it Needle provides a solid, flexible solution. R.