# Aspect Oriented Programming in PHP - Thread: https://externals.io/message/62422 - Original archive: https://news-web.php.net/php.internals/62422 - Started by Peter Nguyen on 2012-08-23T14:36:58+00:00 - Messages: 21 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #62422 — Peter Nguyen — 2012-08-23T14:36:58+00:00 URL: https://externals.io/message/62422#62422 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 AOP in PHP directly. I was wondering if there are any interests/possibility to include AOP into the PHP core? Best regards, Peter --- ## #62423 — William Betts — 2012-08-23T14:59:24+00:00 URL: https://externals.io/message/62422#62423 · In reply to: #62422 > 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 > AOP in PHP directly. I was wondering if there are any interests/possibility > to include AOP into the PHP core? > > Best regards, > > Peter 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? --- ## #62426 — Peter Nguyen — 2012-08-23T15:26:05+00:00 URL: https://externals.io/message/62422#62426 · In reply to: #62423 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 William Betts > > > […] > is > > […] > enable > > […] > interests/possibility > > […] > > 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? --- ## #62431 — Pierre Joye — 2012-08-23T16:16:17+00:00 URL: https://externals.io/message/62422#62431 · In reply to: #62422 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 now (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? http://pecl.php.net/package/AOP looking for feedback, contribs, etc. For the record here :) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #62434 — Ralph Schindler — 2012-08-23T20:11:04+00:00 URL: https://externals.io/message/62422#62434 · In reply to: #62431 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 > hi, > > > > […] > > http://pecl.php.net/package/AOP > > looking for feedback, contribs, etc. > > For the record here :) > > Cheers, --- ## #62435 — Yahav Gindi Bar — 2012-08-23T20:20:26+00:00 URL: https://externals.io/message/62422#62435 · In reply to: #62434 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 being included in core. > > -ralph > > > > > > […] > > -- > > > > I like it too :), though I think that we shall improve it and at least give user the ability to disable the hooking option (for example, any class dealing with payment would like to do that). 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') ) Cheers! :) --- ## #62437 — Sebastian Krebs — 2012-08-23T20:54:42+00:00 URL: https://externals.io/message/62422#62437 · In reply to: #62422 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) 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 > AOP in PHP directly. I was wondering if there are any interests/possibility > to include AOP into the PHP core? > > Best regards, > > Peter --- ## #62440 — Ivan Enderlin @ Hoa — 2012-08-24T05:15:27+00:00 URL: https://externals.io/message/62422#62440 · In reply to: #62422 > 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 now (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? +1! AOP is very useful when making some safeness or security tools, like tests automation (with contracts for making Design-by-Contract or Contract Driven Testing). It avoids to instrument the code each time, which is a drawn-out/laborious task. I would really like to see this extension in the core. I'm sure that it will be useful for so many people and so many tools (each time you need cross-logic in your application architecture actually). Best regards. -- Ivan Enderlin Developer of Hoa http://hoa.42/ or http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ --- ## #62441 — Evan Coury — 2012-08-24T05:41:23+00:00 URL: https://externals.io/message/62422#62441 · In reply to: #62422 > > 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 > AOP in PHP directly. I was wondering if there are any > interests/possibility > to include AOP into the PHP core? +1. Recently there's been a trend towards modular design in the various frameworks and PHP in general. I believe supporting AOP in some capacity in core would help to foster this mentality and would obviously improve the extensibility of existing modules/bundles/libraries/etc. The result would be more opportunities for code reuse and less inferior, duplicate implementations of the same old wheel, as third party extensions for existing code could be made much more powerful. -- Evan Coury --- ## #62442 — Peter Nguyen — 2012-08-24T06:08:00+00:00 URL: https://externals.io/message/62422#62442 · In reply to: #62437 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 Krebs > 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, > > […] --- ## #62443 — Sebastian Krebs — 2012-08-24T06:28:45+00:00 URL: https://externals.io/message/62422#62443 · In reply to: #62442 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 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 > > > […] > -- github.com/KingCrunch --- ## #62444 — Peter Nguyen — 2012-08-24T07:01:14+00:00 URL: https://externals.io/message/62422#62444 · In reply to: #62443 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 > 2012/8/24 Peter Nguyen > > > […] > places > > […] > > > 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 > > > > > […] > (but > > […] > hard > > […] > attached > > […] > soon > > […] > http://en.wikipedia.org/wiki/Aspect-oriented_programming>) > > […] > There > > […] > https://github.com/AOP-PHP/AOP>) > > […] > > > -- > github.com/KingCrunch --- ## #62450 — dukeofgaming — 2012-08-24T15:34:56+00:00 URL: https://externals.io/message/62422#62450 · In reply to: #62444 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). > 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 > > > […] > not > > […] > mentioned > > […] > that > > […] > joint > > […] > will > > […] > several > > […] --- ## #62451 — Lester Caine — 2012-08-24T16:12:54+00:00 URL: https://externals.io/message/62422#62451 · In reply to: #62450 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 CMS frameworks to use it? THAT would be a good example of how good it is ;) Seriously, there are a lot of styles of programming and many of us are stuck in our ways and are more than happy for all these extra bolt on features are kept where they are best placed in the likes of PECL. It's difficult enough keeping existing code up to date without looking to change the entire code base style we are using :) -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #62453 — Ralph Schindler — 2012-08-24T17:06:49+00:00 URL: https://externals.io/message/62422#62453 · In reply to: #62435 > 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 controller actions aop_add_before( 'MySite\Controller\UserController->*Action()', array($this, 'adviseUserController') ); Also, the object has not been created yet (there is no $obj), but I know I want to catch particular objects by a particular type. I do not know what currently happens if I keyed on an instanceof instead of an exact type. I don't think you can successfully translate a wildcard match to a callable array and have the same meaning conveyed as clearly. What I don't want is a more complex syntax than that is already supported. -ralph --- ## #62454 — Anthony Ferrara — 2012-08-24T17:18:40+00:00 URL: https://externals.io/message/62422#62454 · In reply to: #62450 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 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). > > > > > […] > can > > […] > The > > […] > stuff I > > […] > easy > > […] > happens > > […] > this > > […] > get > > […] > look > > […] --- ## #62455 — Peter Nguyen — 2012-08-24T18:36:22+00:00 URL: https://externals.io/message/62422#62455 · In reply to: #62454 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 pattern? Do you need to decorate all your classes before hand just to be futureproof? What do you do if you stumple upon code you need to hook into with no decorator? AOP solves this in a nice way without the need to "pollute" your code. Just think of the possiblities, not having to deal with do_action/add_action again or to think about all the possible events that you need to support in your code for it to be modular. With AOP, you can just write your class and feel safe that there will be a way to hook into your methods without modifying it if you ever need to. 2012/8/24 Anthony Ferrara > 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 wrote: > > > […] --- ## #62456 — Anthony Ferrara — 2012-08-24T19:14:24+00:00 URL: https://externals.io/message/62422#62456 · In reply to: #62455 Peter, > 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 functionality proposed, it applies to *all* instances of a class. That's fine, except when you only want to add the functionality to one instance. > 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 pattern? Do you need to decorate all your classes before hand just > to be futureproof? What do you do if you stumple upon code you need to hook > into with no decorator? No, you just decorate each piece of functionality onto the class. That's the point of a decorator. You don't need to worry about it, you just wrap whatever was there. So you can put decorator on top of decorator. You compose the functionality in layers. And "decorate all your classes before hand just to be futureproof?" tells me you haven't worked with decorators much, as that's a bit of a silly comment. You decorate to change behavior in a specific way. Let's take a canonical example: interface Coffee { public function getPrice(); } class BlackCoffee implements Coffee{ public function getPrice() { return 1; } } class Cream implements Coffee { protected $coffee; public function __construct(Coffee $coffee) { $this->coffee = $coffee; } public function getPrice() { return 0.25 + $this->coffee->getPrice(); } } class Sugar implements Coffee { protected $coffee; public function __construct(Coffee $coffee) { $this->coffee = $coffee; } public function getPrice() { return 0.50 + $this->coffee->getPrice(); } } $creamAndSugar = new Sugar(new Cream(new BlackCoffee)); $creamOnly = new Cream(new BlackCoffee); $sugarOnly = new Sugar(new BlackCoffee); I didn't de-deuplicate (by creating an abstract decorator) to illustrate the concept of what's going on. So no, you don't create a decorator for every class. You create one for each class you need to add functionality to, when you need to add functionality to it. If you want to hook into code without a decorator, you write a decorator. It's that simple. > AOP solves this in a nice way without the need to "pollute" your code. > Just think of the possiblities, not having to deal with > do_action/add_action again or to think about all the possible events that > you need to support in your code for it to be modular. With AOP, you can > just write your class and feel safe that there will be a way to hook into > your methods without modifying it if you ever need to. > Actually, I'd argue this the AOP addition is polluting code more, because it's always global. And global is the antithesis to flexibility (which is the entire point of AOP after all). If it worked on a per-object level, I could see that argument. But seeing as it's global at the class level, I don't think that argument flies. Now, as I said in my prior post, I am actually in favor of this change. I think it can make patching existing architectures and legacy code much easier. But I wouldn't write new code with it. And I wouldn't say that it's a good compliment to OOP. It can help in certain situations, but it also can cause a lot of pain (due to the global nature, and the fact that it is really just spooky-action-at-a-distance). http://en.wikipedia.org/wiki/Action_at_a_distance_(computer_programming) Anthony --- ## #62457 — Peter Nguyen — 2012-08-24T19:53:55+00:00 URL: https://externals.io/message/62422#62457 · In reply to: #62456 Anthony, 2012/8/24 Anthony Ferrara > Peter, > > > > > […] > > > Actually, I think it's the other way around. Think about this for a > second. With the AOP functionality proposed, it applies to *all* instances > of a class. That's fine, except when you only want to add the functionality > to one instance. > You should of course use the right tool for the job, there's nothing stopping you from using any OOP pattern together with AOP. > > > […] > > > No, you just decorate each piece of functionality onto the class. That's > the point of a decorator. You don't need to worry about it, you just wrap > whatever was there. So you can put decorator on top of decorator. You > compose the functionality in layers. > > And "decorate all your classes before hand just to be futureproof?" tells > me you haven't worked with decorators much, as that's a bit of a silly > comment. You decorate to change behavior in a specific way. Let's take > a canonical example: > I was of course exaggerating trying to make my point. Taking a look at your example, it is not really a use case for AOP. For example, you don't apply the Cream class to the User class or the Company class, because it doesn't make sense. But what do you do, when you want to apply a Logging class to all the database actions? Do you really want to decorate all the classes that uses the database? It's even worst when it's somebody else's project. Another thing is that you need to change the calling code to use your new decorator class, what if that code is scattered in your project? You don't need to worry about that if AOP is available. > interface Coffee { > public function getPrice(); > } > class BlackCoffee implements Coffee{ > public function getPrice() { return 1; } > } > class Cream implements Coffee { > protected $coffee; > public function __construct(Coffee $coffee) { > $this->coffee = $coffee; > } > public function getPrice() { return 0.25 + $this->coffee->getPrice(); } > } > class Sugar implements Coffee { > protected $coffee; > public function __construct(Coffee $coffee) { > $this->coffee = $coffee; > } > public function getPrice() { return 0.50 + $this->coffee->getPrice(); } > } > > $creamAndSugar = new Sugar(new Cream(new BlackCoffee)); > $creamOnly = new Cream(new BlackCoffee); > $sugarOnly = new Sugar(new BlackCoffee); > > I didn't de-deuplicate (by creating an abstract decorator) to illustrate > the concept of what's going on. > > So no, you don't create a decorator for every class. You create one for > each class you need to add functionality to, when you need to add > functionality to it. > > If you want to hook into code without a decorator, you write a decorator. > It's that simple. > > > > […] > > Actually, I'd argue this the AOP addition is polluting code more, because > it's always global. And global is the antithesis to flexibility (which is > the entire point of AOP after all). If it worked on a per-object level, I > could see that argument. But seeing as it's global at the class level, I > don't think that argument flies. > Saying that because it's global, it's a bad thing doesn't seem to be a valid point in my opinion. There are many global concepts in programming, like Logging/Authorization/Database connections etc. In fact it is one of the strong argument for AOP, because it will not be of much use if you only can point cut the execution of one class don't you think? But I'm in favor of being able to organize aspects into namespace though, it will be a nice addition to the proposal. > Now, as I said in my prior post, I am actually in favor of this change. I > think it can make patching existing architectures and legacy code much > easier. But I wouldn't write new code with it. And I wouldn't say that it's > a good compliment to OOP. It can help in certain situations, but it also > can cause a lot of pain (due to the global nature, and the fact that it is > really just spooky-action-at-a-distance). > http://en.wikipedia.org/wiki/Action_at_a_distance_(computer_programming) > > Anthony --- ## #62458 — Gustavo Lopes — 2012-08-24T21:00:25+00:00 URL: https://externals.io/message/62422#62458 · In reply to: #62454 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 would just > decorate the object you want to interact with, and you're set. Then just > add your functionality where it's needed. > I think you're missing the fundamental difference between decorators and AOP or interceptors. Decorators augment the object with domain-specific additions, while interceptors are more appropriate for orthogonal concerns. CDI (JSR 299/346) has both. Their interceptors are slightly different from traditional AOP in that you don't have the usual pointcut syntax, and decoration is done is done automatically upon injection. You might want to take a look nevertheless; this is the weld (CDI reference implementation) documentation: * http://docs.jboss.org/weld/reference/latest/en-US/html/interceptors.html * http://docs.jboss.org/weld/reference/latest/en-US/html/decorators.html -- Gustavo Lopes --- ## #62474 — Peter Nguyen — 2012-08-25T10:31:18+00:00 URL: https://externals.io/message/62422#62474 · In reply to: #62422 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.