Phabstractic: Generic Event (Universal Event System)

asherwunk/phabstractic now implements a common event object, useful in the “Universal Event System”.

The Universal Event System

What I call the universal event system is basically several constructs built on top of the Publisher/Observer design pattern that asherwunk/phabstractic also implements.  The idea is that certain events happen in code, and objects listening for those events are notified.  I have built objects that include an actor, a conduit, a handler, which act on events, funnel events, categorize and fire off lists of actions, etc.

The Generic Event

The core of this system is the event object which I have designed to be very versatile.  The event object has many fields on it, including line number, file, tags, categories, and such, all of which are optional.  I decided events would be the “state” change that is observed in the Publisher/Observer design pattern I implemented.  If you remember, the StateInterface in that case looks like this (github):

As usual, with my PHP designs, I’ve implemented an interface for a generic event first.  I’ve decided I want to keep track of a couple things.  First, we’lll give each event an identifier that is going to be unique, or should be unique, to each event object.  Then I thought about how events are used in other frameworks, and one of the things that stood out to me was that an event usually has a ‘target’ that links to the object or memory address that fired the event, or is associated with the event.  So I have a target.  On top of that I took a cue from WordPress actually and decided that each event would have categories and tags, much like a WordPress post.  Also, an event should be able to carry some kind of ‘payload’ or data associated with that event, so I added a data property.  The event can also indicate what class, method, and namespace fired the event.  I took some inspiration from other event systems, including the JavaScript browser event system that “bubbles.”  In this event system events that are fired will ‘bubble’ up to parents.  I took some liberty with this idea in later constructs of the Universal Event System, but the idea that an event would continue through a chain of things stuck with me, so I decided there should be functions to force/subdue an event.  I ended up with this interface (github):

From there it’s a hop to the AbstractEvent.  This implements the basic functionality of a GenericEvent object that applies to all implementations.  For instance, the AbstractEvent handles the implementation of the tags and categories as Sets (see the asherwunk/phabstractic abstract data type Sets post).  As well, it handles all the non-implementation specific property setting and getting that we outlined above in the interface.  This includes the stoppable, subdue-able, data, tags, etc. properties.  The identifier and how to set the data of the event are really the most implementation specific things not quite covered by the AbstractEvent.  Below you can see how I implemented the tags, the translations from objects to arrays and such, and the constructor in AbstractEvent (github):

That brings us to the actual implementation of GenericEvent.  This is pretty simple, it basically picks up where AbstractEvent leaves off.  This means that we have to implement a constructor for the identifier, and we have to implement the methods that set the data ‘payload’ of the event object.  Pretty simple stuff (github):


By associating so much information with a simple event, including arbitrary data, we can build an event framework with a lot of subtlety.  It is possible to build filters then that can decide when and where to further propagate events based on their tags or categories for instance (and in fact we do, stay tuned!)  It is possible then to build objects that act like a “Front Controller” for events in a whole system, what I call a “conduit”.

Events are powerful objects/concepts and enable a ‘reactive’ programming paradigm, where pieces of program code execute only when certain things happen.  You can think of it sort of like this: with procedural we go from start to finish, with object oriented we go from object to object, and with events we jump around based on what else happens in the rest of the program.  Events are a powerful flow-control mechanism that can be used for many purposes.

This is part of the Phabstractic Library.

If you appreciate my programming please help support me through my Patreon.

photo credit: Alex-de-Haas The Musician. via photopin (license)

Liked it? Take a second to support kadar on Patreon!


I'm just a wunk, trying to enjoy life. I am a cofounder of http// and I like computers, code, creativity, and friends.

You may also like...

Leave a Reply

%d bloggers like this: