Aspect-Oriented PHP

Bryan Saunders writes "

I am Bryan Saunders, and together with John Stamey and Matthew Cameron, we have developed an Extension to PHP to enable you to do Aspect-Oriented Programming with PHP. AOPHP 1.0 currently supports basic Before, After, and Around advice. Future versions will have more advanced support for these three types of advice. The Extension was developed using Java 1.5 and runs on Apache Web Servers. There are two parts to the implementation of AOPHP. The first involves using the Apache module ModRewrite, "the Swiss Army Knife of URL manipulation." The second is the aophpexec.aophp script which calls the AOPHP parser, written in Java 1.5. Aspects are written with a .aophp extension. These aspects are woven into incoming .php files by the Java AOPHP parser, contained in aophp.jar. For more information on AOPHP, visit http://www.aophp.net/ and For information on Aspect-Oriented Programming, visit http://www.aosd.net/ and http://www.aspectorientedprogramming.org/."

Comments

Re:Please Explain

[Heftklammerdosierer!]

O'Reilly On Java seems much more straightforward than the two links in the writeup, although I just googled "aspect oriented programming intro"...

Re:Please Explain

[Samus]

I'm not sure about the full what can and can't it do but from what I understand aop is about eliminating cross cutting concerns from your objects. For instance an application might need security and in every secured method you would code up a security check. That same check might be done in 100 places and be pretty much the same code. AOP allows you to take that code and put it in an aspect which is then inserted into a cut-point. Typical cut-points are before execution and after execution. Security is one example. Another might be database transactions. This is what I have gleaned from it all without actually getting that in depth with it. Java has a number of fairly mature implementations such as AspectJ and many of the IoC containers like Spring. JBOSS 4.0 also has an aspect implementation but again I haven't had the time to check it out. Different implementations insert the aspects into the cut-points differently though. Some use bytecode manipulating libraries like asm or bcel to do it at runtime. Others like AspectJ do it at compile time. Spring (a lightweight container) will create a proxy class if you are using an interface or resort to byte code manipulation if you are using a concrete class. Other lightweight containers are probably similar.

Re:Please Explain

[Anonymous Coward]

It's just a way to add functionality to a bunch of methods at once without having to add the code to each one.

If you use Ruby, for instance, you can do a trick like this to intercept a method call and do your own stuff:

class Fixnum
alias old_plus +
def +(other)
puts "I'm about to add #{self} and #{other}"
result = old_plus(other)
puts "There, I've done it and got #{result}"
puts "But I'm going to be naughty and return 42 instead"
42
end
end

puts "4 + 5 = #{4 + 5}"

Just imagine some code that does this automatically, with easier syntax, and lets you specify a whole bunch of methods across a whole bunch of classes and you've got AOP.

For instance, you could say "add the following logging code to all methods matching /.*send/, in all classes".

Handy for debugging, logging, rapid prototyping, etc.

NOT a paradigm shift, a successor to OOP, or anything like that. Just a way to make life easier for folks stuck with non-dynamic languages.

Re:Please Explain

[pijokela]

My experience (mostly theoretical) is with AspectJ (Java), but I guess that doesn't really matter. The simple explanation I would give is this:

You define Pointcuts which are points in you application execution such as: before the start of a method that matches a regular expression (like set.*).

You define Advice that is a function/method that is executed at a given pointcut.

And then your code is executed e.g. before a setter method is called on some/any objects. This allows you to open transactions as they are needed or handle exceptions outside the business code. Probably allows you to do all kinds of other stuff too, but those are the two obvious things that I've come up with.

Just write a PHP extension..

[gabe]

Why implement it in Java? Why not just create a Zend/PHP extension using C, interface with the Zend engine's byte code executor and intercept function / method calls and execute advise functions before and after?

Then all you'd need is a single function to call in PHP like this:

aop_register_advice('my_function', 'my_advice_function', BEFORE_CALL);
aop_register_advice(array($myobj, 'myMethod'), 'my_advice_function', AFTER_CALL);

Code already exists to perform this kind of interception in PHP debuggers / profilers like APD and Xdebug.

One great aspect of open source is that, frequently, the code you need will probably already have been written. (pun intended)

Re:Please Explain

[cgreuter]

The reductionist answer is that it lets you attach hooks (i.e. function calls) to various program actions (other function calls, variable accesses, etc.) in a methodical sort of way. The big-picture reason for this is that you can then (in theory) separate out parts of the program that would normally have to be smooshed together into the one module.

For example, say we have a web application framework in which you go from one page to another by calling one of several functions whose names begin with "GotoPage". Now, on this web app, you need to:

1. Log the transitions from each page to the next.
2. Do security checks to make sure the user is actually allowed to go there.

In the usual way of doing things, you'd have to put calls to the security and logging subsystems in each GotoPage* function. In AOP, you'd instead write them as separate modules and then hook them to the GotoPage* functions. That way, the different aspects of the problem--page transitions, security and logging--are handled by different modules. This means that:

1. Each aspect can be written and maintained independently and without (a lot of) concern over the other aspects. Thus, the web-app team can focus on just the web functionality and leave the problem of security to the security team without either of them needing to do a lot of coordination.
2. The code is more readable because each section focuses on doing just one thing.
3. If you need to add some other aspects (e.g. distributed objects), you can just add it by writing the module and hooking it in, all without modifying any of the original code.

It seems like a neat idea, although I'm not sold on it yet. One problem that I can see is that the source code doesn't necessarily do what it says it's doing anymore. Buggy aspects can introduce errors into correct code. I'm not sure how/if that's been solved.

(Disclaimer: I haven't actually done any AOP. I've just read about it.)

It's to save effort in by reducing repetition

[Julian Morrison]

IANAAOP but I think I get it enough to explain.

The purpose of AOP is to reduce repetition. Rather than writing repetitious tasks (like eg: security permission checking) into each function over and over, you write it once and attach it to all affected functions.

Taking that example of security, you can do it in non-AOP by just inserting a checkSecurity() call in front of each function - but you might miss some out and it's hard to maintain all that scattered code.

So, the big difference in AOP that I've noticed is: you can define this sort of "cross cutting" task in one place - and "push" it onto all the relevant functions from that same one place, rather than "pulling" it from each function with a call. This is IIRC usually done with some sort of regex, so you can say "all functions called security_foo (for any foo) get permission checked. Then if you add the new security_wibble() function, it will get checked without need to add or maintain checking code. Similarly, pre-existing functions that match the regex will be drawn into the checking too - you don't need to hunt them all up and make alterations in each.

Re:OK let me get this straight.

[jbwiv]

Umm...no

You run the PHP through the AOP tool after writing the PHP...new PHP spits out, and then you post *that* code to your site. No slowdown...