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 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
