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

[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

[web_boyo_in_sac]

some professors can't explain the "Why" just the "How" but with the hundreds of thousands of readers here, someone should have a good explination so think about it 1-3 likely identical descriptions, or 40-50 like but different descriptions, which would you choose?

Re:Please Explain

[Lally Singh]

different ways to intercept and modify method invocations.

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.

Re:Please Explain

[Hard_Code]

It's a way to implement cross-cutting concerns in languages that don't natively have a facility to do such a thing.

Take for example logging. If you wanted to log the beginning and end of every function, you could edit all the functions and add log calls to the beginning and end. "Aspects" allow you to, for instance, say, you want given code executed for a matching set of functions.

Re:Please Explain

[silicon not in the v]

After reading the summary and then even the comments here, I'm still looking for the button to switch Slashdot back to English.

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

Re:Please Explain

[Malevolyn]

I suppose it'd be similar to regular while loops using next or continue, but more of a spacial sense as it's "Do this() after that()." As opposed to setting a variable and acting based on its value, like this:

this();
$didthis = 1;
if ($didthis) { that(); }

Re:Please Explain

[Malevolyn]

Forgot the while example, which could be something like...

while ($a = array_pop($b)) {
if (this()) next;
$a++;
continue;
}

Re:Please Explain

[Anonymous Coward]

Procedural programming describes the series of actions, or programmatic steps, necessary to complete tasks. The coding of many distinct tasks can involve similar actions or design decisions. Embedding code to directly perform these actions, or embody these decisions or assumptions, makes the software less flexible (and therefore less reusable), and often less maintainable and harder to test.

In contrast, AOP encourages separation of distinct concerns, so that an aspect of a software system or sub-systems behaviour can be easily specified or changed. A very basic ways of implementing AOP philosophy is by separating different functional elements in to distinct libraries (e.g. a logging library, a security library, a thread-safety library), and never directly outputting logging information to assumed streams, calling TCP connect(), or using pthread_mutex(). All such conceptual actions must be made through the library, so that the extra-library software's behaviour can be modified. For example, library changes could instantly see an entire application uniformly perform no logging; logging via a remote logging server, SMS or email; partial/filtered logging etc.. Alternatively, connect() could internally invoke SSL routines, or pthread_mutex() could be a non-operation in a single-threaded process.

So - there's nothing very new about that idea. What's interesting is making it practical, and less costly in function-call overheads (which in some compilation/linkage/execution environments prevent inlining, reducing performance by an order of magnitude).

C++ offers inlining and templates, which can typically be used to implement AOP philosophy without performance penalty. See books like Modern C++ Design by Alexandrescu. C offers a preprocessor (#defines) which is ugly and error-prone, but capable of similar performance efficiencies.

Many of the posts describe automated post-facto changes to pre-existing code, which is powerful but potentially dangerous, as there's no guarantee that the code being changed has been written with anticipation of the kind of changes being made to it. Careless modifications could, in some situations, produce unexpected side effects like deadlocks or infinite recursion. People debugging problems would have to be very careful to consider whether the code they're examining is actually the code that executed with bugs.

Still, exploration of AOP techniques is essential for increased efficiency in software reuse.

Tony Delroy tony_in_da_uk a t yahoo.co.uk

Re:Please Explain

[Trifthen]

Forgive me if I'm wrong, but isn't this already addressed by object-oriented programming? Separate module for security? Logging? How about a security object, a logging object, and so on? Objects are just black boxes anyway... who cares what they do, so long as they say they do it?

I mean... properly designed code has a known execution and procedural chart. If you have an object that just makes use of a bunch of other modules, and trusts what they say, you've done your goal of code separation. Aspect programming seems to break all of the rules of programming in general. So the question remains: why?

Re:Please Explain

[cgreuter]

Forgive me if I'm wrong, but isn't this already addressed by object-oriented programming?

Not precisely. The big advantage (AIUI) of AOP is not the idea of putting the different aspects of the program into black boxes--that's already been done. The Big Thing is how the black boxes are connected together, something that is orthogonal to the nature of the black box.

Without AOP, you'd have to explicitly connect the black boxes (be they objects, modules or functions) from inside. AOP lets you connect them at the public interfaces.

For example, in a straight non-aspect OOP version of my hypothetical web-app framework, you'd need to explicitly call "DoSecurity" and "DoLogging" from inside each "GotoPage*". Thus, you need to connect the black boxes from inside another of the black boxes. This means that in order to get them all to work, you need inside knowledge of at least one of the black boxes.

In the AOP version, the calls to DoSecurity and DoLogging are hooked to calls to the public interface, so you can do it without needing to see inside any of them.

(Disclaimer: I'm not an AOP expert so if any genuine AOP authorities want to step in and correct me, now is a good time.)

Re:Please Explain

[RAMMS EIN]

Thanks for the explanation. Apparently, I do understand AOP. I just couldn't believe that this is really all there's to it.

Re:Please Explain

[Trifthen]

I still don't think that makes any sense. That's what a 3rd-party facilitator object is for:

(Pseudocode)

class wrapper
{
oSecurity = NULL;
oLogger = NULL;

wrapper()
{
this->oSecurity = new Security_Object();
this->oLogger = new Logger_Object();
}

logsecurity()
{
this->oSecurity->doSomethingSecure();
this->oLogger->logSomething("Did Security!");
}
}

There. Public interface calls of two black-boxes tied together. All you need to have is the documentation for the public API calls. I just must not understand. ^_^

Why Java

[Anonymous Coward]

Why put java into the mix? I can't think of any other reason than the authors realy, realy don't want this to be used anywhere. The compiler seems so trivial that it should be no problem coding it in php.

Honest question:

[Jerf]

Honest question. Does anyone in the PHP care about this? Last I knew, they were just getting into objects with a halfway decent (though a little kooky) system. Isn't the PHP community mostly just people who want to bash out webpages, with the rest made up of people who think it's a good platform for large-scale frameworks?

I'm not trying to dis the community, those are valid concerns and there should be a tool for those people. But ISTM that AOP is much more likely to succeed in Java than PHP; one might as well try to introduce AOP to Visual Basic users. Hmmm... heh.

I think in Python so the whole idea of calling it a "paradigm" is a bit foreign to me anyhow; I was using it, as relevant, before it had a name, and I know LISPers were, too. A "technique", yes, a valuable one, but I'm not sure it is worth loading it down with the baggage of being a "paradigm" so much as a "good OO technique that is easier with language support but still possible without".

Re:Honest question:

[web_boyo_in_sac]

well being that are ARE just now getting "real" OOP into PHP, this would be the perfect time to start incorporating AOP. When do you put tires on a car? After it gets axles but before you try to drive it. Hopefully this concept gets incorporated into the standard PHP build eventually, much like a couple dozen modules that are there for hardcore users, the "average" php home basher won't use them, but they are there for those of us that do use them.

Re:Honest question:

[Anonymous Coward]

Probably not.

Anybody who is advanced enough to think about AOP probably outgrew PHP a LONG time ago. You can't even dynamically add methods to PHP classes or dynamically modify the methods on an existing class. There are no hooks called before and after method calls, etc. No way to access the syntax tree of a class.

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!

It's easy in LISP of course (like everything else).

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

What's funny is people who think AOP is something like the next step after OOP or something. "I'm going to write my program in AOP instead of OOP" ..??

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.

Re:Honest question:

[Fweeky]

None of the PHP developers I know will even give this a second look thanks to it using Java (and sounding like a complete hack). It's not even worth looking at with requirements like that, unless you're seriously desperate for AOP.

"Isn't the PHP community mostly just people who want to bash out webpages, with the rest made up of people who think it's a good platform for large-scale frameworks?"

Not quite; you missed out the people who don't think PHP's a good platform for anything significant, but who use it anyway because, well, what else is there that they know and other people will use/support?

"I think in Python so the whole idea of calling it a "paradigm" is a bit foreign to me anyhow"

What's AOP like in Python? It's pretty easy in Ruby; there's no direct language support, but it's easily added with reflection and code generation.

Re:Honest question:

[Hard_Code]

What boggles me is that if you are going so far as to write a PHP parser in Java - why on God's earth would you not just create a PHP->JSP translator!? Solve the problem once and for all.

Re:Honest question:

[chris_mahan]

Because JSP is not supposed to be used for business logic, only for presentation. All JSPs are compiled to servlets prior to use.

PHP-> servlet translation, now, that would be something (not).

(By the way, I have a fat J2EE book in front of me, and that's what is says at the beginning of the JSP chapter.

Re:Honest question:

[Anonymous Coward]

why on God's earth would you not just create a PHP->JSP translator.

Well, JSP requires a servlet container. Most of the people I know who use PHP use it because it's a lighter weight solution than J2EE. If you're going to require a servlet container, you're better off using AspectJ. Then again, the implementation here seems to be bass ackwards and far from light weight, so this thing seems next to useless anyways.

Re:Honest question:

[aled]

and sounding like a complete hack

Indeed, that what I thought the first time I saw PHP...

Re:Honest question:

[Anonymous Coward]

With PHP 5, a lot of things aren't quite as you portray them anymore.

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

Classkit does a lot towards this end, though it's not enabled by default, I believe.

There are no hooks called before and after method calls, etc. No way to access the syntax tree of a class.

There aren't any hooks, this is true. One could extend a class and place the hooks in the new version (even using the __get and __call functions to make a generic wrapping class). Still, I recognize this isn't a particularly workable solution in many cases.

The syntax tree of a class can be accessed via reflection.

Re:Honest question:

[haystor]

You have to figure there are two main classes of PHP programmer. The on making web pages and the one making modules that make web pages. AOPHP might be useful to someone making something like PHPNuke (or not, I won't pretend to know). 99% of PHP programmers will likely never even hear about this.

Re:Honest question:

[ahdeoz]

Thats rediculous. PHP has both an eval() function and "variable variables" $$foo

Re:Honest question:

[Jerf]

I think you missed on the "reply" button. (I've done that too.) Your post makes no sense as a reply to mine, but it probably makes sense somewhere else.

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:AOP is patented

[tiptone]

i believe that someone has a patent on an implementation of AOP, not on AOP in general. isn't that how it works?

Re:AOP is patented

[btsaunde]

We have already spoken to Gregor Kiczales (the patent holder) about the AOPHP project and he was greatly interested in it. He has encouraged us to continue the development of this project, so i do not tihnk he will be trying to sue us.

Re:AOP is patented

[Matt Perry]

Excellent. Thanks for the follow up.

Re:AOP is patented

[Anonymous Coward]

Just to clarify, the patent is actually held by Xerox, or the Palo Alto Research Center, not any of the individual inventors.

I've said it before

[Valar]

and I'll say it again:

Witchcraft!

Brought to you by a fist shaking, angst ridden C coder.

WTF?

[albalbo]

Redirect all my URLs to a PHP script which is going to call some Java parser which presumably then spits out PHP which is then interpreted?

Either I'm nuts or they are.

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

Is it just me...

[Anonymous Coward]

or do the authors only know how to do things in Java? Of course, since Sun (betcha didn't know that was an acronym for Stanford University Network) has endorsed PHP as the scripting companion for Java after failing to provide any meaningful evidence that Java scaled better than PHP makes it ok to think of the two as having some sort of symbiotic relationship.

Don't get me wrong, I think Java is a good solution for a certain set of problems (I haven't found any that I can't solve with other existing solutions, but I'm not a techno-bandwagoner like some folks), but not the end-all, be-all that Sun and the other "faithful" (read fanatics) claim it is. From my experience, it pretty well is an underperformer with more hype than reality (qualification: I've worked with Java since before version 1.0 and I'm still waiting for something more than a kind of Visual Basic for the Internet).

The AOPHP project seems to simply add more overhead and requires more system resources, exactly the kind of thing I know that everyone wants (seriously, I always have my clients come to me and ask for software that requires more hardware and still offers lower performance all the time ---- NOT!!!!).

But perhaps I'm just feeling curmudgeonly this morning and your actual mileage may vary...

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:Just write a PHP extension..

[btsaunde]

the purpose of the aspect is essentially to be able to change the way the program executes with out changing the code. users should not have to register there functions to there advice, they should be able to simply code the advice in the aspect file and it automatically be weaved into the script, they should not have to make any modifications to the PHP script itself for aspects.

OK let me get this straight.

[Spy der Mann]

You're using a java-compiled tool to make php scripts more powerful?

OK, i've heard of PHP extensions.
"PHP + compiled Extension"

But now, you want us to do
"PHP + Extension + JVM" ???

I don't want to troll, but... doesn't that make PHP run slower? Of course, if anyone can correct me, please tell me where i'm wrong.

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:OK let me get this straight.

[btsaunde]

In the Testing we have performed thus far, it appears to have no noticable impact on the speed of the execution of the scripts.

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.

The patent probably wouldn't hold up

[ShatteredDream]

It is a very vague patent that covers an entire paradigm of programming, not a specific implementation of any sort. For example, if Microsoft were to create "AspectVB" they could patent AOP programming for Visual Basic since it is a fairly specific idea. AOP however is an abstract idea that cuts across dozens of legitimate implementations.

IANAL, but I just don't see how they could actually use this patent to trash a specific implementation. They haven't gone after AspectJ so this is probably just a defensive patent anyway to make it impossible for big corporations to patent AOP in general.

Re:The patent probably wouldn't hold up

[Anonymous Coward]

True, it probably wouldn't hold up, but that wouldn't be determined until you visit the courts, and at that point, you've already wasted time and resources. You may not even be able to use your "infringing" code during the whole legal process. So, it is a problem.

Doesn't do anything new ...

[louismullie]

This whole "aspect-oriented" thing doesnt do anything that wasnt done before. There are many OO patterns that do the same job and dont incur the overhead of having a Java (!) extension. MVC (Model-View-Controller, http://c2.com/cgi/wiki?ModelViewController) separates the controller (which handles which "GotoPage" method to use), the view which handles all the presentation, the templating, etc. and the model, that actually does the logic part. Couple that with the intercepting filter pattern (basically, a chain of responsibility), which has the controller and an authenticate filter, and one filter per aspect, and you have a well-designed, reusable OO solution to the aspect problem. Aspect-oriented is just another word for layering, and layering has been the choice for software architecture for a long time.