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: http://qntm.org/loco 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... On Sun, Aug 26, 2012 at 2:34 PM, Peter Nguyen <pe...@likipe.se> wrote: > 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 <ras...@mindplay.dk> > >> > >> > On Thu, Aug 23, 2012 at 7:36 AM, Peter Nguyen <pe...@likipe.se> 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 >> 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... >> > >
