I just wanted to give you a quick heads up! Other then that, superb blog!

In your examples, the problem is not the use of the singleton design pattern but rather the junction of a model class (an object that is independent from the MVC application and that typically would represent an external resource, from a database or similar) with an object that is intrinsically tied to the Symfony MVC application pattern, which itself is entirely tied to, as you explained, the request, controller and view ensemble.

Regardless, the singleton design pattern is a useful development pattern which has its advantages (ensure uniqueness of an instance, provide single-point access to a resource/model) and its drawbacks (such as preventing garbage collection). Be smart, use it when it applies.

To use a practical example, think about a component that sends e-mail via SMTP – this is the kind of thing where you’re typically going to want some kind of diagnostic facility when it’s running in production. So many people will simply add a $debug flag to the class, and this will toggle some internal logging feature on or off.

The problem with that is, logging diagnostic messages has nothing to do with the sending e-mail – and because logging can be done in 100 different ways, this introduces scope creep and eventually multiple different logging-methods and some way to toggle them, which is way beyond what an e-mail component should do.

Modern PHP has closures, so we can now solve this by simply adding a callback property (e.g. $onLog) to the class – and suddenly, all the SMTP class needs to knows about logging is that messages exist. Everything else can be delegated to a programmer, who can choose to plug in his favorite logger, test-framework, Twitter API, a simple echo-statement during development, or whatever madness you see fit.

Sure, turning on logging now is a bit more work than just raising a boolean flag – but I think we all need to get more comfortable writing a couple of lines in a closure and think of it as “configuration”, even if it is code. It’ll make our lives easier in the long run.

It says : **Symfony Event Dispatcher has its roots in the Apple Cocoa notification center.** So I guess you are misinformed. And I don’t see how this relates to Hibernate or Django…

But I was indeed wrong on one point: they got the NIH syndrom 5 years later, not 3.

And in case you are wondering why Symfony2 isn’t just using the Event system from Doctrine Common. We actually looked at it and determined for the flexibility that Symfony2 needs Doctrine would have made changes that would have had a severe impact on its performance. We tried to see if there was a way to share the core logic, but determined that it wasn’t possible.

Furthermore if you look at your code from back then, its using stuff like return by reference. I am sure that it can be rewritten to PHP5 with reasonable effort, but its not like it would have made sense to use as is nor that its a lot of lines of code to write an event dispatcher. It basically boils down to picking one of the algorithms already implemented out there and then making it work in PHP.