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
> > >
> >
>
