I am going to address IoC issues only on this thread. The other repeatability issues should be address, but on the other thread.
On Mon, Jan 18, 2010 at 7:10 AM, Sean Owen <sro...@gmail.com> wrote: > > I am not especially in favor of my own Random patch. If people are > > willing to run in 'fork-once' mode to get the clock time down, and > > prefer to stick with the uncommons RNG, then it's not useful. > > > > Since anything has benefits and drawbacks, my question is which has > the highest benefit-to-drawback ratio. > +1 at the high level. > > Formal dependency injection is heavy, even with this Bus or Guice: > - Requires artifical change to API > Not too large. For Guice, it requires a constructor with the injectables. This is easy and probably good anyway. > - Config files > The Guice equivalent is a Module which provides the bindings between interfaces and implementations and a little bit of annotation. This is a small cost (but a definite cost). > - More library code or dependency to implement > I don't see this. Could be true. > - Less 'readable': harder to see what's actually being used > My experience with Spring is that it definitely is less readable because you have to read reams of XML which wasn't designed to be read. There are hacks upon hacks design to improve this, but it is still a major problem. Guice seems vastly more readable given that it just uses java. The readability loss that I see is that you don't know what implementation would be used for any injectable class, but I haven't found that a problem with that since I can look at the implementations very quickly. Summary on costs from my point of view, 2 x +0.5, 1 x +0, 1 x -0.5, net weak agreement but I seem to think the costs are less than Sean thinks. Interesting, he is the one who has actually used Guice in production as opposed to my experience of using Spring. > Benefits are: > - Flexibility to swap out depedencies across the board at runtime > - Doing it one way reduces errors as opposed to reimplementing > injection by hand 10 times > +2 The major impact of the first point is that we can do better testing. In fact, my feeling is that testing is the biggest benefit overall of most IoC frameworks. > If Random is the only candidate, I don't think it's worth it, and it > ends up being overengineering: who's realistically going to need to > change the RNG, and we have only 1 instance, and no obvious candidates > for injection besides at the moment. +1 -1 The other obvious candidates would be the various clustering frame works/drivers, the DP implementation models, the new SGD code for injection of loss functions. Plausibly Taste could use IoC for injecting various kinds of distances and such. In general, I don't advocate wholesale rewrites of working code, but I think that the real reason that we don't have any obvious uses of IoC is that we haven't had IoC to use. Compare the overhead with, > literally, 10 lines of simple code. > For the random case, I think that hand-written constructor level injection of a generator is no more effort than using a static block. I also count the use of any static as nearly as evil as using a global variable. -- Ted Dunning, CTO DeepDyve
