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
technique that requires code-generation, in some form or another,
including code-manipulation, pre-processing, transpilers, and so
forth: traceability of errors.
languages that are popular as intermediary languages generally support a
directive that makes it possible to trace errors back to their source.
I raised this issue on the list recently, and no one seemed to react with
any interest...
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 rasmus@mindplay.dk
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
technique that requires code-generation, in some form or another,
including code-manipulation, pre-processing, transpilers, and so
forth: traceability of errors.languages that are popular as intermediary languages generally support a
directive that makes it possible to trace errors back to their source.I raised this issue on the list recently, and no one seemed to react with
any interest...
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 about the details, and hence not a good candidate for a
language feature, in my opinion.
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:
For something like an aspect-oriented language extension and pre-processor,
you could get a head start on parsing enhanced PHP syntax really quickly.
Also, consider how much simpler it would be to implement things like
template engines...
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 rasmus@mindplay.dk
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
technique that requires code-generation, in some form or another,
including code-manipulation, pre-processing, transpilers, and so
forth: traceability of errors.languages that are popular as intermediary languages generally support a
directive that makes it possible to trace errors back to their source.I raised this issue on the list recently, and no one seemed to react with
any interest...
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
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.comwrote:
But AOP is just one of many popular techniques that require code
generation. And for that matter, there is an endless number of differentI'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