Aspect Oriented Programming in PHP View as Markdown

This is exactly the "problem" that AOP solves. I think the decorator
pattern is just a solution for the shortcoming of the language itself. What
if you want multiple advices at that joint point, do you create decorator
on decorator, call another class inside the decorator, or use the observer
pattern? Do you need to decorate all your classes before hand just to be
futureproof? What do you do if you stumple upon code you need to hook into
with no decorator?

AOP solves this in a nice way without the need to "pollute" your code. Just
think of the possiblities, not having to deal with do_action/add_action
again or to think about all the possible events that you need to support
in your code for it to be modular. With AOP, you can just write your class
and feel safe that there will be a way to hook into your methods without
modifying it if you ever need to.

2012/8/24 Anthony Ferrara ircmaxell@gmail.com

Just a pedantic note here. You don't need any special functionality to do
AOP style programming in PHP. In fact, this use-case is the exact
definition of a Decorator.

Instead of hooking in with a function call and cut-points, you would just
decorate the object you want to interact with, and you're set. Then just
add your functionality where it's needed.

class Foo {
public function sayIt() {
echo "world";
}
}

class Bar {
protected $foo;
public function __construct(Foo $foo) {
$this->foo = $foo;
}
public function sayIt() {
echo "Hello ";
$this->foo->sayIt();
}
}

(new Bar(new Foo))->sayIt(); //Hello World

Now, I know that this AOP extension allows you to decorate all instances
of a class without even having an instance to decorate (since it's done by
class name, instead of object instance). So it's not exactly the same, but
from a design perspective both achieve the same thing.

In fact, the decorator can be more flexible due to the fact that you can
control if (and when) you call the wrapped object's method.

Note that I'm not saying that I'm against adding AOP hooks. I'm just
saying that it's not really an OOP construct. In fact, it's not an OOP
construct. That's fine, that doesn't diminish its usefulness. Just that
it's not strictly necessary as you can already do the same thing with
traditional OOP constructs...

Anthony

On Fri, Aug 24, 2012 at 11:34 AM, dukeofgaming dukeofgaming@gmail.comwrote:

AOP is the future and a very awesome complement to OOP. It is a shame that
very few are doing it and I think this would attract some good attention
to
PHP after traits (both are horizontal reuse mechanisms).

Well, you just have to know and check for the aspects I guess, if you're
using wildcards in the joint points. It's no difference than knowing
what
PHP functions/classes/variables not to overwrite/overload. Besides, you
can
always debug_backtrace to find out which joint points was executed...
Another option is not to use wildcards and define the joint point
explicitly.

2012/8/24 Sebastian Krebs krebs.seb@gmail.com

2012/8/24 Peter Nguyen peter@likipe.se

Your argument is a general issue when refactoring code. Whenever you
change the name of a method/class, you need to change it in all the
places
that use it, even in the AOP definitions if you have it of course.
The
advice is just a PHP callable so it works in the same way.

I talked about refactoring the joint points, not the advises, but
thats
not
the point. If I refacter an identifier my IDE (I use PhpStorm, but the
others should be that powerful too) supports me by searching for every
occurence of the identifier, or even without the need to refactor
stuff I
can call "find usage". With a string like

$ 'Classname::method()'

or

$ 'Classname->method()'

I need at least text search, that should work reliable, when no
dynamic
strings occur, because with

$ 'Classname::' . $method

it's getting hard, if not even impossible. One default case (it's
mentioned
in the quickstart of the extension) are the wildcards

$ 'Classname::do*()

I guess this would take much effort. Just "refactoring" is not that
easy
anymore.

Don't get me wrong: I like AOP as idea and as concept, but I'm afraid,
that
it could lead to scary construction, where noone can trace, what
happens
when and why. Also as I mentioned I don't even have any better idea ;)

Regards,
Sebastian

2012/8/23 Sebastian Krebs krebs.seb@gmail.com

Hi,

From my users point of view: I would like to see it. Maybe not in
this
implementation/syntax, especially because it hasn't a special
syntax
(but
imo it should to make the impact more obvious/prominent). With the
joint
points as string and the common function call I can imagine it can
get
hard
to find out, where a specific advise where attached, or which were
attached
at all, or just how many. For example I rename a method/class and I
will
not recognize, that a security advise gets lost, I may realize it
as
soon
as I find my data on pastebin ;) But I have no idea how it could
look
like....

Regards,
Sebastian

Am 23.08.2012 16:36, schrieb Peter Nguyen:

Hi,

AOP (http://en.wikipedia.org/wiki/**Aspect-oriented_programming<;
http://en.wikipedia.org/wiki/Aspect-oriented_programming>;)
when used
correctly, can make your application really modular. I've seen
several
implementations but they all require compiling of code beforehand.
There
is
however a PECL extension now (https://github.com/AOP-PHP/**AOP<;
https://github.com/AOP-PHP/AOP>;)
that enable
AOP in PHP directly. I was wondering if there are any
interests/possibility
to include AOP into the PHP core?

Best regards,

Peter

--

--
github.com/KingCrunch

On Fri, 24 Aug 2012 19:18:40 +0200, Anthony Ferrara ircmaxell@gmail.com
wrote:

Just a pedantic note here. You don't need any special functionality to do
AOP style programming in PHP. In fact, this use-case is the exact
definition of a Decorator.

Instead of hooking in with a function call and cut-points, you would just
decorate the object you want to interact with, and you're set. Then just
add your functionality where it's needed.

I think you're missing the fundamental difference between decorators and
AOP or interceptors. Decorators augment the object with domain-specific
additions, while interceptors are more appropriate for orthogonal concerns.

CDI (JSR 299/346) has both. Their interceptors are slightly different from
traditional AOP in that you don't have the usual pointcut syntax, and
decoration is done is done automatically upon injection. You might want to
take a look nevertheless; this is the weld (CDI reference implementation)
documentation:

• http://docs.jboss.org/weld/reference/latest/en-US/html/interceptors.html
• http://docs.jboss.org/weld/reference/latest/en-US/html/decorators.html

--
Gustavo Lopes