AOP is not very well understood, it took me at least a week of going back and forth trying to grasp the core concepts. Before getting into debates (because the Observer & Event patterns could still allow for AOP-like programming), I advice everybody to watch the following two videos
Using Aspect Oriented Programming to Prevent Application Attacks (6 parts, very practical explanations and code examples): http://www.youtube.com/watch?v=c-492qXrT6w http://www.youtube.com/watch?v=jOqQpbk--jQ http://www.youtube.com/watch?v=tMHr34Empvo http://www.youtube.com/watch?v=A63g4xSvb1Y http://www.youtube.com/watch?v=-0U5LzLkPkY http://www.youtube.com/watch?v=PygweFC5VKM After you are finished, watch Aspect Oriented Programming: Radical Research in Modularity, which is a Google Tech Talk by Gregor Kiczales ( http://en.wikipedia.org/wiki/Gregor_Kiczales): http://en.wikipedia.org/wiki/Gregor_Kiczales In a nutshell, AOP could be said to be a gramatical extension to give languages the formal expressiveness to natively allow for decorating/observing/metaprogramming(code generation)/reflective behaviors, which can avoid lots of code duplication and increase performance & modularity. I also would also advice everybody to look into AspectJ: http://en.wikipedia.org/wiki/AspectJ http://www.eclipse.org/aspectj/ Regards, David On Mon, Aug 27, 2012 at 1:06 AM, Ralph Schindler <ra...@ralphschindler.com>wrote: > On 8/26/12 7:21 PM, Rasmus Schultz wrote: > >> But AOP is just one of many popular techniques that require code >> generation. And for that matter, there is an endless number of different >> > > I'm failing to see what code generation you talking about. Could you > elaborate about how AOP and code generation relate? > > > I would much prefer to see the language enhanced on a lower level - to >> enable solid, reliable, efficient implementations of code generation in >> userland, paving the way for good AOP frameworks, as well as many other >> techniques and ideas, now and in the future. >> >> Thanks to bytecode caching, and various other advances in efficiency in >> the >> past few years, PHP in general is (or could be) a brilliant language for >> code-generation tasks. For instance, check out this elegant parser >> library: >> > > The benefit of AOP as a low-level (it is as low level as say, xdebug) > extension is massive. > > AOP solves the problem of cross cutting concerns. In PHP, if you don't > want to rely on globally accessible API's, solving this problem usually > entails injecting another object. So now, your $controller object is > injected with a $logger object, $authentication object, $session object, > $caching object, etc. > > Currently, all of the major frameworks are attempting to provide AOP > stylings though a Javascript-esque event/signal manager. To do this, code > must be littered with something like the following: > > class Foo { > public function doA() { > $events->trigger('beforeA', $this); > // actually do A > $events->trigger('afterA', $this); > } > public function doB() { > $events->trigger('beforeB', $this); > // actually do A > $events->trigger('afterB', $this); > } > // repeat for every other interesting method > } > > Now, $events could be a dependency, it could be some object that shares a > static scope, or it could actually be a static call like Events::trigger(). > Whatever the case, any code that wants to subscribe to this AOP-esque > style of allowing non-descript collaborators to "advise" or coalesce into > the workflow has to follow this pattern .. all over the place. $this might > be $this, but in many cases, it is a context object that bundles up > necessary info including $this. > > With ext/AOP, all of that goes away. Objects can get back to just doing > what their core objective was (even application services / models / > controllers) and they don't have to care that a logger now wants to log > something about what a controller is doing, or (taken a step further) that > somewhere in the code an authentication aspect was registered to ensure a > particular set of controllers is only accessed by users who are logged in. > > In short, the only aspect of this particular extension that does anything > slightly related to parsing is it has a syntax for doing the "engine level" > hooking. (Think of is as a DSL/syntax for setting smart breakpoints with a > debugger). > > > Also, consider how much simpler it would be to implement things like >> template engines... >> > > Not sure I follow here either. > > -ralph > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
