I want to state very clearly that this does not intend to revive the discussion about functional/procedural programming versus object-oriented programming. There is plenty said about that, on WPSE and all over the net.
But a while ago I’m reading over some of the discussions about the programming foundations of WordPress and I read something – I have to rephrase because unfortunately I didn’t bookmarked it at the time – roughly like this:
One of the appealing things about using WordPress is that they are additionally working based on the event-driven paradigm of programming.
From what I understand event-driven programming in this context is pretty much synonym to signal or dataflow programming. Furthermore – most likely oversimplifying it a lot – maybe the main apparent characteristic is the use of hooks – actions and filters – as linchpin for the method.
So far so good. Seems easy enough, but I’m not coming from a computer science background, so I’m pretty sure there is more to be said. I’m really interested in some input, like: What is it really about or is the above said pretty much it? Is it an extra paradigm? How does it relate to the other ones? Is it a core principle or just an addition?
Those are just off the top of my head, clearly breaching the rules, by not asking one singular question that has one distinct answer, but maybe this will be forgiven for once.
First of all lets clarify what
paradigmword means in the programming. It means that we come to an agreement that we will handle certain cases/issues/situations in a certain way.For instance, we come to agreements that foot-passenger should cross a road on a green light in our country. This is our green light paradigm. In another country could be an agreement to cross a road on a raised hand. That is their raised hand paradigm. They are not related to each other, they just exists and foot passenger could use either paradigm or create his own cross a road whenever I want paradigm.
The same situation is in the programming. Paradigm is just a set of rules or agreements to develop an application in a certain way or use a certain approach. Nothing more.
Ok, get back to WordPress and event driven paradigm. This paradigm is only one part of whole WordPress system. This paradigm sets a bunch of rules/agreements how to extend the core by 3rd party extensions, where hooks for actions and filters are linchpin approach. Pay attention that this paradigm covers only expansibility cases/issues/situations and this is not only paradigm used by WordPress, but is one of the core ones.
That’s all. Of course you can use your own write a plugin/theme how I want paradigm and be happy with it 🙂
I think that with event driven paradigm, who write article intends Observer Pattern.
And that in WordPress is handled via the Plugins Api. I don’t think there’s much more to say.
@nicolai: WordPress follows Publisher Subscriber variant of The Observer pattern (Event Driven Architecture).
WordPress is event driven because of the limitations of the language it is written in, not because it is in any way designed to be such.
The most popular web servers are event driven and PHP out of the box has very little utilities (none ?) to behave in any other way. Since wordpress depends on PHP, it just can not be anything else.
The PHP part of WordPress plugins and themes OTOH should be designed to be event driven by “events” “sent” by core. JS code is also event driven, but the events are almost only those triggered by an actual users (although some of the wordpress JS code will abstract it as well and raise events of its own).