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 <ircmax...@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 <dukeofgam...@gmail.com>wrote:
>
>> 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).
>>
>> On Fri, Aug 24, 2012 at 2:01 AM, Peter Nguyen <pe...@likipe.se> wrote:
>>
>> > 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....@gmail.com>
>> >
>> > > 2012/8/24 Peter Nguyen <pe...@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....@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
>> > > >>>
>> > > >>>
>> > > >>
>> > > >> --
>> > > >> PHP Internals - PHP Runtime Development Mailing List
>> > > >> To unsubscribe, visit: http://www.php.net/unsub.php
>> > > >>
>> > > >>
>> > > >
>> > >
>> > >
>> > > --
>> > > github.com/KingCrunch
>> > >
>> >
>>
>
>
