On Mon, Jan 18, 2010 at 2:59 PM, Benson Margulies <bimargul...@gmail.com> wrote: > Doing significant work in static code blocks leads to nothing but > trouble, as the Random situation demonstrates.
I don't know that this is the conclusion? You're critiquing one means of implementing injection, but neither of the two problems identified in the last few days (performance, repeatability) had anything to do with the implementation per se. > 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. Formal dependency injection is heavy, even with this Bus or Guice: - Requires artifical change to API - Config files - More library code or dependency to implement - Less 'readable': harder to see what's actually being used 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 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. Compare the overhead with, literally, 10 lines of simple code. ... can I try again to drag attention to an actual problem? the repeatability issue. This injection discussion is orthogonal to it.
