> (services not using other services) meant services not used by other services
Simon Chemouil racontait le 03/06/2014 21:20: > Gary Dusbabek racontait le 03/06/2014 19:59: >> This has come up before. Let's face it, removing the singletons is a >> tempting proposition. >> >> Several of us have been down the path of trying to do it. >> >> At the end of the day, here's what you'd end up with (absolutely best case): >> >> 1. Modifying just about every class, sometimes substantially. >> 2. A huge patch for someone else to review. >> 3. No performance gains, no bug fixes. In fact, since so many classes have >> to be changed, I'd say that the risk of introducing a bug/regression is >> fairly likely. >> 4. Complicated merges when bugs need to be fixed in older versions. >> 5. More modular and testable code. >> >> So far, the positive aspects of 5 have not been able to trump the >> challenges presented by 1, 2, 3, and 4. > > Thanks for your reply. I understand the reasoning, yet obviously I think > your 5th point weighs a lot more than the others, because it also means > more hackable code, and though a huge patch might be scary, seeing so > many static fields is scary as well ;). > > We could make the patch more manageable by splitting it in several > patches, one per 'service', and start from the leaves of the dependency > graph (services not using other services), but we'd have to apply the > patches in a specific order. Still, it would make it easier to review. > > The 3rd point is I guess usual in the life of an healthy project: fixing > the 'technical debt' the project accumulated over the years seems almost > as important as fixing bugs and improving performance. While doing it, > we would also port the tests and hopefully introduce new tests to make > sure we didn't introduce bugs, and generally be careful we don't break > anything. Yes, there might be new bugs, probably the kind of bugs that > are already there but lurking because of the initialization order or > relying on specific side-effects, but those already exist and might pop > out any time. Refactoring this code seems, for the most part, to be a > fairly repetitive process and doing it carefully should allow to avoid > most bugs introduced by inattention. > > The (4) is an important problem, but merging this would probably mean a > major version bump (e.g, within the 3.0.0 branch), and at some point in > time, older versions will reach their EOL. It seems to me that only bug > fixes are backported, and the patches already have to be adapted for the > 1.x branch... But unless people give up entirely on the idea of fixing > this, this problem is going to become worse as time goes by. > > Cheers, > > Simon > > >> Kind Regards, >> >> Gary. >> >> >>> >>> Cheers, >>> >>> -- >>> Simon >>> >>> >>> [1] >>> >>> http://grokbase.com/t/cassandra/dev/107xr48hek/creating-two-instances-in-code >>> >> >
