Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62554
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <503B0E65.6090904@ralphschindler.com>
References: <CADqTB_gJR_qR7CXqaysJ0Qt9iriqZhjscemNoKOh-MmS-8hAxg@mail.gmail.com>
 <CAP1dRQ7EPmVKqrt22GBSuVkRmwB0ot9j4iWr-SDWGERaNLwc=g@mail.gmail.com>
 <CADqTB_ju6mF+U_vGKydRT_51aWir3wyE_R2ZLcOQuDpPc28zzg@mail.gmail.com> <503B0E65.6090904@ralphschindler.com>
Date: Mon, 27 Aug 2012 01:33:01 -0500
Message-ID: <CAFt2z-=KNyNRkt-_VDf8JKSNRV1c3rmu23JSF+KrKd=q7Kw9Qw@mail.gmail.com>
To: Ralph Schindler <ralph@ralphschindler.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=bcaec5171c7985131f04c839805c
Subject: Re: [PHP-DEV] Aspect Oriented Programming in PHP
From: dukeofgaming@gmail.com (dukeofgaming)

--bcaec5171c7985131f04c839805c
Content-Type: text/plain; charset=ISO-8859-1

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:

> 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
>
>

--bcaec5171c7985131f04c839805c--