From: Jamis Buck Date: 2004-10-12T01:44:20+09:00 Subject: Re: DI service change notifications (Needle ne Syringe) Eivind Eklund wrote: > On Tue, 12 Oct 2004 00:48:05 +0900, Jamis Buck wrote: >>Indeed. However, if this kind of functionality were to be put into the >>core of the framework, I would personally prefer to see it robust enough >>to either capture all dependencies, regardless of where or how they are >>created, or none of them. Given Syringe's current implementation, I >>don't think an efficient, general-purpose solution meeting that >>criterion can be devised. I'd love to be proven wrong, though. :) > > > I don't think any can be devised, period. And thus, I think that the > design criterion is inappropriate - if a problem is too hard, find a > smaller and better problem to solve :-) True, but only if it's a problem worth solving. :) In my experience with DI, I've never needed to query the dependency graph. That doesn't mean it isn't a useful feature--I'm just saying it isn't something that would get used very often. That said, is it worth spending a ton of effort on? According to the 80-20 rule--I say not. Does the currently implementation require a violation of DRY, as you pointed out, to accomplish dependency graph traversal? Yes. But given how often that feature is needed, I think it's a fair trade. If, down the road, my assumptions are proven false, I'll be happy to rip the internals apart and rebuild them to support this feature. But I've got more immediately useful features to solidify first. :) This whole needle framework is very experimental at this stage. If someone else wants to hack on the sources and add dependency graph traversal, feel free. Needle will be in CVS on RubyForge (pending approval) within the next few days. I will be glad of any submitted patches. > In this case, I think that being able to register the dependency tree > for the cases where somebody declares all of their construction "in > the same place" might be useful. I also guess this covers at least > 95% of the relevant cases, and that the cases where the holes are made > will be obvious - and that they won't be obvious if we try to engineer > a "complete" solution. And it is easy to create something that lets > us add an extra manual dependency for those cases. True, but the holes, IMO, introduce an element of surprise. If dependencies are tracked under 95% of the cases, and you don't understand how the system is really working, you would end up with bugs in your code when you declare a dependency differently from the expected process. I'd really rather users of needle not have to understand how needle works its magic. > Having to manually track the dependency trees separately from the > instation heavily violates the Don't Repeat Yourself principle, so if > there is any chance of this being used for complex cases, I think that > a capability to auto-record is important. > > Then again, I've not used any of this in practice, so I may be totally > off the chart. Me, too. :) The only use I've seen for this is the one that Leon posted with being able to refresh a service's implementation and have all services that are dependant upon the refreshed service automatically refresh as well. How often is _that_ needed? I don't know. _I've_ never needed it, but Leon has. No one else has piped up yet to say whether _they've_ needed it, so it's still unclear how generally useful such a feature would be. So, given that we're both kind of shouting into a vacuum here, we might as well just hold off on this until more real-life use cases pop up. :) I'm expecting many different iterations and rewrites of Needle before it is really "mature", since this is an approach to DI that's never been taken before. Thanks, Eivind, for your feedback! It's great food for thought, and it challenges my assumptions, which is always a good thing. -- Jamis Buck jgb3@email.byu.edu http://www.jamisbuck.org/jamis