I think we’re getting a little ahead of ourselves talking about DI frameworks. Before that even becomes something worth talking about, we’d need to have made serious progress on un-spaghettifying Cassandra in the first place. It’s an extremely tall order. Adding a DI framework right now would be like throwing gasoline on a raging tire fire.
Removing singletons seems to come up every 6-12 months, and usually abandoned once people figure out how difficult they are to remove properly. I do think removing them *should* be a long term goal, but we really need something more immediately actionable. Otherwise, nothing’s going to happen, and we’ll be having this discussion again in a year or so when everyone’s angry that Cassandra 5.0 still isn’t ready for production, a year after it’s release. That said, the reason singletons regularly get brought up is because doing extensive testing of anything in Cassandra is pretty much impossible, since the code is basically this big web of interconnected global state. Testing anything in isolation can’t be done, which, for a distributed database, is crazy. It’s a chronic problem that handicaps our ability to release a stable database. At this point, I think a more pragmatic approach would be to draft and enforce some coding standards that can be applied in day to day development that drive incremental improvement of the testing and testability of the project. What should be tested, how it should be tested. How to write new code that talks to the rest of Cassandra and is testable. How to fix bugs in old code in a way that’s testable. We should also have some guidelines around refactoring the wildly untested sections, how to get started, what to do, what not to do, etc. Thoughts?
