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

Please Explain

[RAMMS EIN]

Can someone please try to explain to me what aspect oriented programming is all about?

I've consulted various websites, and I took classes about it, but I still don't get it.

I know it has something to do with modifying the behavior of code after that code has been written. However, all the terminology confuses me. What is it, exactly? What are all the buzzwords? What can and can't it accomplish?

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

[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.

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.)

AOP is patented

[Matt Perry]

Aspect oriented programming is currently patented (US patent 6,467,086). Do you have permission from the patent holder to distribute this work, particularly under the GPL? As an end user, would I be likely to be sued if I use AOPHP in a project? Would the AOPHP developers be sued if I use this in a project? This isn't a troll, just my valid concerns before I spend any time seeing if this would help my development.

Note: yes, I know there is possible prior art to AOP but that doesn't change the fact that the USPTO has issued a patent on it.

Re:Honest question:

[Jerf]

Out of order quoting:

I'm not sure what "thinking in Python" has to do with it though, you can't do a lot of it in Python either!

You can't even dynamically add methods to PHP classes or dynamically modify the methods on an existing class.

Python does that trivially.

There are no hooks called before and after method calls, etc.

There may not be hooks, but it's trivial to do in Python thanks to the previous point. In 2.4, the decorators can do this on a per-method basis, and to translate an entire class is pretty easy with a metaclass. Personally, I have yet to find a situation where this was useful and I didn't end up factoring it out, but I'm sure they exist. (I also have this problem with metaclasses; I keep solving problems with metaclasses, but I invariably factor them out; the only use I've kept for them so far is in cateloging various features of various classes. But that doesn't mean I think they are useless :-) )

No way to access the syntax tree of a class.

The full syntax tree, well, technically it is accessible but not in any useful way, so I'd say that Python can't do this. Generally, this is considered a bad thing in the community anyhow. I'm currently ambivalent; there are times I want it, but I do have to acknowlegde that also each of the times I've wanted it it would have made my code absolutely impenetrable to most programmers.

Easy in Ruby due to the massive amount of runtime hooks and open classes.

My impression is that other than the block syntax, Ruby and Python are as close to identical as you could hope for, and what one language does, the other has features to make up for. And the syntactic differences are a wash because almost every argument one person proffers in favor of one is considered a counter-argument by the other side. My favorite example: Ruby fan: "Ruby is more concise!" Python fan: "Why yes, yes it is, but that makes it less readable." Who is right? Both of them, really, for different people.

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)

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...

Re:WTF?

[btsaunde]

I guess were nuts, because thats how it works. Your PHP Scripts are redirected to the AOPHP Weaver, witch then takes your code, weaves in the aspects, and sends the new PHP w/ Advice added to PHP to be parsed as usual