# Aspect Oriented Programming in PHP

- Thread: https://externals.io/message/62513
- Original archive: https://news-web.php.net/php.internals/62513
- Started by Rasmus Schultz on 2012-08-26T17:51:57+00:00
- Messages: 5
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #62513 — Rasmus Schultz — 2012-08-26T17:51:57+00:00

URL: https://externals.io/message/62513#62513

>
> 
> I know very little about AOP and don't pretend to know a lot, but how
> would we benefit
> from directly adding it into core instead of taking the approach FLOW3 did?


as I see it, the problem with AOP in PHP is the same as with any other
technique that requires code-generation, in some form or another,
including code-manipulation, pre-processing, transpilers, and so
forth: traceability of errors.

languages that are popular as intermediary languages generally support a
directive that makes it possible to trace errors back to their source.

I raised this issue on the list recently, and no one seemed to react with
any interest...

---

## #62524 — Peter Nguyen — 2012-08-26T18:34:11+00:00

URL: https://externals.io/message/62513#62524 · In reply to: #62513

That's why I thnk the extension is superior to all other solutions, because
it doesn't require code generation in userland. Also, it will be possible
to backtrace to the declaration of the aspects.

2012/8/26 Rasmus Schultz <rasmus@mindplay.dk>

> > […]
> did?
>
>
> as I see it, the problem with AOP in PHP is the same as with any other
> technique that requires code-generation, in some form or another,
> including code-manipulation, pre-processing, transpilers, and so
> forth: traceability of errors.
>
> languages that are popular as intermediary languages generally support a
> directive that makes it possible to trace errors back to their source.
>
> I raised this issue on the list recently, and no one seemed to react with
> any interest...

---

## #62542 — Rasmus Schultz — 2012-08-27T00:21:56+00:00

URL: https://externals.io/message/62513#62542 · In reply to: #62524

But AOP is just one of many popular techniques that require code
generation. And for that matter, there is an endless number of different
approaches and features found in different AOP solutions for various
languages - it's not a "one size fits all" idea, many people are going to
have preferences about the details, and hence not a good candidate for a
language feature, in my opinion.

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:

http://qntm.org/loco

For something like an aspect-oriented language extension and pre-processor,
you could get a head start on parsing enhanced PHP syntax really quickly.

Also, consider how much simpler it would be to implement things like
template engines...




> That's why I thnk the extension is superior to all other solutions,
> because it doesn't require code generation in userland. Also, it will be
> possible to backtrace to the declaration of the aspects.
>
>
> 2012/8/26 Rasmus Schultz <rasmus@mindplay.dk>
>
> > […]

---

## #62553 — Ralph Schindler — 2012-08-27T06:06:29+00:00

URL: https://externals.io/message/62513#62553 · In reply to: #62542

> 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

---

## #62554 — dukeofgaming — 2012-08-27T06:33:01+00:00

URL: https://externals.io/message/62513#62554 · In reply to: #62553

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
<ralph@ralphschindler.com>wrote:

> 
>
> > […]
>
> 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
> > […]
>
> 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
> > […]
>
> Not sure I follow here either.
>
> -ralph