PHP: Am I mixing up event-driven programming with signals-aware interfaces (Signal and Slots / Observer Pattern)?

Question

I\'ve seen a lot of people saying that Symfony2, Zend Framework 2 and others are event-driven.

On the desktop world, by event-driven programming I understand that the a

Answer 1

PHP is not stateless, HTTP is. To state it simply, we have essentially built a layer on top of a stateless technology upon which we can implement stateful designs. Taken together, PHP and your datastore of choice have all the tools they need to build an application design based on event driven patterns via the tokenization of sessions.

In a highly generalized way, you can think of HTTP as being for the web what BIOS has been for desktop computing. In fact, take this just a little bit further, and you can easily see the implicit event-driven nature of the web. You said "it's not an event but a whole new request", and I return with, "a whole new request is an event", and I mean that in the design pattern sense of the word. It has concrete semantic meaning relating to your user's interaction with your application.

Essentially, through patterns like MVC and Front Controller (and by the mechanism of HTTP cookies and PHP sessions), we simply restore session state, and then respond to the event, modifying that state accordingly.

I like to contemplate the essence of REST: Representational State Transfer... but I would add that we should not forget the implicit implication that state is only transferred when a UI event has occurred. So we maintain the contracts we have with HTTP that we "speak" only in "Representational States" of our model (i.e. a document, JSON, etc), but that is only our dialect. Other systems choose to speak in canvas coordinates, signal db, etc.

edit/more thoughts

So I've been pondering it for a while and I think there is a concept which illustrates a little of the ambiguity when discussing these patterns in the realm of PHP via HTTP: determinism. Specifically, once a request is received, the path of PHP execution is deterministic, and this is exactly why it's remarkably difficult to consider an "event-driven" architecture in PHP. My notion is that we should consider one level higher than PHP, to the larger "session" of interaction with the user.

In desktop computing, we use runloops and a state-ful context to "wait" for events. However, I will argue that the web is actually an improvement over this architecture (in most cases) but ultimately the same pattern. Instead of a runloop and infinite-duration state, we bootstrap our state when an event occurs and then process that event. And instead of just keeping that state in memory and waiting for the next event, we archive that state and close the resources. It could be considered less efficient in one sense (that we need to load state at every "event"), but it could also be called more efficient in that there is never idle state in memory for no reason. We only load state which is actually being consumed/manipulated

So in this way, think of PHP via HTTP as being event driven at the macro level, while resting assured that any given execution is indeed deterministic and not actually event driven at all. However, we implement a front-controller and MVC pattern so that we can provide application developers with the familiar structure of even driven hooks. When you are working with a decent framework, you simply say "I want to know when a user registers, and the user should be available to me to modify at that time". This is event-driven development. It should not concern you that the framework has bootstrapped the environment for (almost) the sole purpose of calling your hook (vs. the more traditional notion that the environment was already there and you were simply notified of an event). This is what it means to develop PHP in an event-driven way. The controllers determine (based on the request) which event is occurring, and uses whichever mechanism it is designed to use (i.e. observer pattern, hook architecture, etc) to allow your code to handle the event, respond to the event, or whatever nomenclature is most appropriate for your particular framework's semantics.