Matthias Noback has continued his look at event handling in PHP applications (well, Symfony-related ones at least) in his latest post. In this latest post he focuses more on abstracting out the event handling process and decoupling it from your application as much as possible.

You are creating a nice reusable package. Inside the package you want to use events to allow others to hook into your own code. You look at several event managers that are available. [...] Introducing this dependency is not without any problem: everybody who uses my/package in their project will also pull in the [event dispatcher] package, meaning they will now have yet another event dispatcher available in their project (a Laravel one, a Doctrine one, a Symfony one, etc.). This doesn't make sense, especially because event dispatchers all do (or can do) more or less the same thing.

As mentioned, he focuses in on the Symfony ecosystem and the event handlers commonly used there. He talks about some of the disadvantages of the Symfony EventDispatcher and how its interface can lead to code bloat due to it's verbosity (flexibility?). He talks about its violations of the Interface Segregation Principle and how he would structure the listener setup and handling if he was starting from scratch. To this end, he's created an adapter that wraps around an EventDispatcher interface and works with objects for the different kinds of events rather than the string names.