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 O
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
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 a
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
> >
> > On Thu, Aug 23, 2012 at 7:36 AM, Peter Nguyen wrote:
> > I know
>
> On Thu, Aug 23, 2012 at 7:36 AM, Peter Nguyen wrote:
> 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
FYI, there is already namespace support in the extension, and you can also
use type hinting on the pointcuts with interfaces/traits besides class
names.
On Fri, 24 Aug 2012 19:18:40 +0200, Anthony Ferrara
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 wou
Anthony,
2012/8/24 Anthony Ferrara
> Peter,
>
> On Fri, Aug 24, 2012 at 2:36 PM, Peter Nguyen wrote:
>
>> This is exactly the "problem" that AOP solves. I think the decorator
>> pattern is just a solution for the shortcoming of the language itself.
>
>
> Actually, I think it's the other way aro
Peter,
On Fri, Aug 24, 2012 at 2:36 PM, Peter Nguyen wrote:
> This is exactly the "problem" that AOP solves. I think the decorator
> pattern is just a solution for the shortcoming of the language itself.
Actually, I think it's the other way around. Think about this for a second.
With the AOP f
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
patte
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
In addition, I think that the hook syntax has to be changed into the
"call_user_func" one (instead of... "$obj->foo()" do array($obj, 'foo') )
I think the current syntax is fine. Keep in mind, you can use wildcards
in that syntax, I do in my application, for example:
// before all contro
dukeofgaming 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).
That is a bold statement!
Do you have time to convert one of the CM
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 wrote:
> Well, you just have to know and c
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...
Anothe
2012/8/24 Peter Nguyen
> 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 sa
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.
2012/8/23 Sebastian Kreb
On Thu, Aug 23, 2012 at 7:36 AM, Peter Nguyen wrote:
>
> Hi,
>
> AOP (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
> howev
On 23/08/12 16:36, Peter Nguyen wrote:
Hi,
Hi,
AOP (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 no
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
On Thu, Aug 23, 2012 at 11:11 PM, Ralph Schindler
wrote:
> I've started using this extension on a personal project. So far, I really
> love it. If the performance aspects of it remain minimal, and the syntax
> remains simple/non-complex, I can see this as a component that would
> benefit many by
I've started using this extension on a personal project. So far, I
really love it. If the performance aspects of it remain minimal, and
the syntax remains simple/non-complex, I can see this as a component
that would benefit many by being included in core.
-ralph
On 8/23/12 11:16 AM, Pierre
hi,
On Thu, Aug 23, 2012 at 4:36 PM, Peter Nguyen wrote:
> Hi,
>
> AOP (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
> howe
Benefits:
- Standard way to use AOP in PHP without having to use any specific
framework
- No need to recompile code after each change in that particular framework.
- I know too little about C but I would guess that there is more possiblity
to optimize the feature if it's built-in.
2012/8/23 Willi
On Thu, Aug 23, 2012 at 7:36 AM, Peter Nguyen wrote:
> Hi,
>
> AOP (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
Hi,
AOP (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) that enable
26 matches
Mail list logo
