Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming PHP Technology

Aspect-Oriented PHP 51

Posted by timothy from the do-please-explain dept.
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/."

This discussion has been archived. No new comments can be posted.

Aspect-Oriented PHP More

Aspect-Oriented PHP

Comments Filter:

  • Please Explain (Score:3, Interesting)

    by RAMMS+EIN ( 578166 ) on Wednesday January 05, 2005 @03:09PM (#11266357) Homepage Journal
    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?
    • O'Reilly On Java [onjava.com] seems much more straightforward than the two links in the writeup, although I just googled "aspect oriented programming intro"...
    • different ways to intercept and modify method invocations.

    • Re:Please Explain (Score:2, Informative)

      by Samus ( 1382 )
      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 i

    • Re:Please Explain (Score:1, Informative)

      by 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

    • Re:Please Explain (Score:2, Informative)

      by pijokela ( 462279 )
      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 the
    • 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.
    • 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 (Score:5, Informative)

      by cgreuter ( 82182 ) on Wednesday January 05, 2005 @08:03PM (#11270551)

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

      • 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

        • 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 th

          • 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 f
      • Thanks for the explanation. Apparently, I do understand AOP. I just couldn't believe that this is really all there's to it.
    • 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 not
    • 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(); }
  • 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 a
    • 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.
    • 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
      • 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.
        • 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.
      • and sounding like a complete hack

        Indeed, that what I thought the first time I saw PHP...
    • 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.

  • AOP is patented (Score:3, Interesting)

    by Matt Perry ( 793115 ) <perry.matt54@ya[ ].com ['hoo' in gap]> on Wednesday January 05, 2005 @04:13PM (#11267352)
    Aspect oriented programming is currently patented (US patent 6,467,086 [uspto.gov]). 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.

    • i believe that someone has a patent on an implementation of AOP, not on AOP in general. isn't that how it works?
    • 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 defensi
    • 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.
  • and I'll say it again:

    Witchcraft!

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

  • WTF? (Score:2)

    by albalbo ( 33890 )
    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? (Score:2, Interesting)

      by btsaunde ( 846884 )
      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

  • Just write a PHP extension.. (Score:3, Informative)

    by gabe ( 6734 ) on Wednesday January 05, 2005 @06:25PM (#11269469) Homepage Journal
    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 [communityconnect.com] and Xdebug [xdebug.org].

    One great aspect of open source is that, frequently, the code you need will probably already have been written. (pun intended)
    • 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.
  • 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.
  • 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 ch

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close