Less boilerplate FTW (+ newInstanceWithoutConstructor won't allow bypassing ;) )

Thanks to various comments, I figured out a better API for this global clock.

There is no setter anymore.

To use a custom clock, one now has to call Clock::with($clock, $callable, ...$arguments). This ensures the previous clock is restored after $callable has completed.

Do not add it to the API, please! I'm begging you! 🙏 It is easy to achieve by simple wrapper when it is really needed.

Static calls to some global state can be useful in some code, but most of the time it leads to maintenance problems and bugs. People would use it without reason if that was in the API.

The feature looks like Laravels Facades. Every time I've seen them used, they are used wrong. Not because the Facades are something bad, but because developers (especially not very experienced) do bad things with them. Facades are constantly overused/abused just because it is convenient, they are described in guides, and "they all do that, why I shouldn't?"

The good answer to how to inject time (and other dependencies) into Doctrines' entities is repository. Repositories are the best place to provide entities, including new ones. If it's difficult in your case or doesn't suit your needs, there are many other options #48564 (comment) But... Please, do not add static calls to the API.

I plead guilty to having a Clock singleton class on my project. It is indeed the simplest way to replace the new DateTime(); even if a dependency injection properly done would be clearer.

With this implementation, I don't see how I could override the current time for functional testing. I can redefine the clock service, but how do I override Clock::now()? Encapsulate the transaction like this?

$client = static::createClient();
$crawler = Clock::with($mockClock, fn() => $client->request('GET', '/'));

@GromNaN you nailed it :)

I added Clock::get([$newClock]): ClockInterface back since I realized that forcing a closure around might not fit all styles - eg a pre+post event listener.

Thanks for the feedback. PR updated. It now provides integration with services + phpunit.

PR description updated.

Why is there a now() function exactly? If we have a singleton already it seems simple enough to do Clock::get()->now(). Functions are not "lazily" imported (not autoloaded) and it can be added easily in userland if needed, in the other hands we need to add some rules to be sure we don't use this function in our code.