What Happened to Aspect-Oriented PHP?

It's not every day that you find a lost branch of a programming language. However, Aspect-Oriented PHP (AOPHP) is one such artifact.  Borrowing much from the general concept of AOP, it might have become a full-fledged extension of PHP, but for one reason or another, it never took off.

Wikipedia defines Aspect-Oriented Programming (AOP) as:

a programming paradigm which isolates secondary or supporting functions from the main program's business logic. It aims to increase modularity by allowing the separation of cross-cutting concerns, forming a basis for aspect-oriented software development.

That's pretty dense, but basically AOP tries to solve the problem of fragmented code.  Object-Oriented Programming did the same thing by adding classes and objects. AOP attempts to solve a different problems (cross-cutting concerns) with different constructs, namely Aspects.   Despite the fact that there has been some traction in other languages such as Java, C++ and C#, a PHP variant never caught on.

AOPHP was apparently started in early 2005 as a research project by John Stamey and Bryan Saunders but for unknown reasons it did not get popular and was loosely maintained for a number of years.  Since about 2007, the topic hasn't really been talked about much —  perhaps among other reasons, because PHP doesn't seem to attract the scholarly computer-science types.

So what the heck is a Cross-Cutting Concern?

To explain what it IS, it helps to explain, first, what it's NOT. The classic example is that if you consider an XML parser in procedural terms you would probably create dozens of functions and each one would take a reference to some data structure.  There isn't any clear boundary or encapsulation between the XML parser code and production code.

If we take that same example and apply Object-Oriented Programming methodologies, you would have an XmlParser class with functions and references attached to it.   With OOP you get clear boundaries defined, and common code related to XML parsing stays in one localized place.

If I tried to explain AOP using the XML parser example, I would fail to do it justice.  AOP actually works very well alongside Object-Oriented programming.  But, a good example is a logging system.  No doubt you've written something like this.

  1. function foo()
  2. {
  3.     customLog("starting foo");
  4.     // ... do some work
  5.     customLog("finished foo");
  6. }

The problem is that we repeat too much code.  A cross-cutting concern is one where related code (in this case, logging statements) is found scattered across an application.  Log calls are a good example because they are typically found all over an app.  If we, later, wanted to exchange our logging class for a different one, it would require updating every call (affecting many systems).  This would be a small issue with most websites, but if we're talking about corporate infrastructure code... Well, I wouldn't want to do it.

How does AOPHP  solve these problems?

AOP, as a theory, provides some interesting functionality.  For example, consider how difficult it would be to implement the phrase "Wherever we get data from the database log the transaction and inputs." Programming that could take weeks.  Just imagine modifying all of that (functioning) code and inserting the proper log statements for each situation. Errors would ensue. If code can smell, this one smells like duplication of effort.

Many programming languages try to simulate natural language with their syntax, and this is where AOP shines (theoretically).  We could produce some pseudocode like the following:

before each database transaction
    log input parameters and a timestamp

With AOPHP the implementation would look something like the following — very similar to the pseudocode.

  1. aspect DatabaseLogging {
  2.     pointcut databaseAccess = execr(mysql_query($sql));
  3.     before($sql): databaseAccess {
  4.         customLog("Accessing Database: {$sql}");
  5.     }
  6. }

Remember, this applies to every database call — and you don't need to write an adapter class!

Okay, so it might not be a stellar example, but think about patching all those oddites of PHP that you already do.  Things like escaping variables, CSRF protection, session handling, and various types of form validation.  Personally I would love to have these features and not have to think about check every time I need them.

Does PHP even need it?

At this point, PHP probably doesn't need AOP.  There are enough Reflection API functions like __call and __get which allow a programmer to intercept function calls dynamically.  And the PHP developers seem to be having enough difficulty adapting to unicode... So this kind of stuff will probably remain for just language nerds like myself.  (And actually I'm not using, just writing about it.)  But certainly, much of the acclaim made about Ruby is due to it's metaprogramming — which is very AOP-esque.

Notable attempts at Aspect-Oriented PHP:

(As far as I know, none of these are production ready.)

Leave a Reply