ebook later, get it out there asap, would like to read. My thinking is very similar to your own.
Its actually something we've been doing for an API at work. The main reason was so we can easily port legacy code [read hundreds of includes/ and that type of fluff] into a PSR compliant system pretty much on the fly without having to jump through all the hoops of a framework - all while still having access to everything in packagist.
>People love to write build system after build system, in every field, a fetish I've never quite understood.
I have a firm suspicion its what writing a framework, cms, or blogging platform used to be.
In time the leader will show itself and people will get the message that this project is no longer fun and trendy.
I have to agree makefiles are pretty much the be all and end all when it comes to building projects. It offers pretty much all the power you could need.
The only plausible reason for makefiles to not be suitable for a culture brought up on shiny macbooks and "GUI's" would be that not many people want to deal with the complexity which comes from having that much power.
Take this for example. Its pretty hard to look at let alone understand. That scare is probably reason enough alone for a bunch of wheel2.0s to be created. The 183 page plain text manual doesnt help much either. Its too daunting for today's culture.
Its just not about being correct and feature complete anymore, its about having the path of least resistance. Simple makefiles are simple, but nobody upvotes a hacker news article about how amazingly easy makefiles are.
Is anyone a little more versed in US law able to explain what kind of precedent this sets for further cases in Iowa or I'm guessing to be nation wide due to the judge being federal?
I could be a bit off base, and to be honest am only now coming to grips with unit testing fully, but I find if something is painful to test my implementation wasn't good to begin with. I'm guessing this is where writing tests first really comes in handy as you have to implement in the right way from the start.
In my case a cache could be something remote, having any calls directly to that will slow down unit tests a lot, having one or two calls to it unit testing the cache implementation it self is OK, but having every method which makes use of it make those calls isn't going to work.
In reply to your original question, its not extremely bad if you can't unit test that class alone , but in this case you wouldn't be able to unit test anything which uses it either.
Not only can you mock it for testing but it encapsulates the system better, there is no reason for straight access to C.get with this pattern you can easily drop in a brand new system for caching and not break your original code. Some might find that a bit too much like coding for the future, but in my case that is quite a likely situation to occur especially if you ever run into scaling issues.