Slashdot Mirror


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

1 of 51 comments (clear)

  1. Re:Please Explain by cgreuter · · Score: 4, Informative

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