AOP finds extensive application in the Java ecosystem. Taking into account the current trends and the evolutionary trajectory of Java, the proxy - based approach appears to be the most viable and efficient solution.
To implement a proxy - based AOP solution, one can make use of ProxyManager\Factory\AccessInterceptorValueHolderFactory and incorporate a CompilerPass that iterates through the services. This combination enables the successful realization of such an AOP solution.
However, it's worth noting that this particular solution has a high degree of reliance on the container implementation. Moreover, a significant number of developers tend to utilize only select Symfony components rather than the entire Symfony framework. Given these circumstances, it seems to me that implementing this within the Symfony framework might not be the most ideal choice. Instead, it could be more appropriately developed as a separate bundle.

The idea sounds great.

Nevertheless, the proxy approach have some other limitations: this cannot be done with final class or final methods, and I don't think this proxy stuff can be done thanks to PHP 8.4 proxy mechanism.

If using VarDumper component's virtual proxies, another problem could be that it cannot "proxify" methods which might return this

Yes, that would be other limitations, and we could throw an exception at compile time to let devs know that the interceptors cannot be applied if the class or method is declared as final

Although if the service is an interface it should viable as decorating the original service will be the only option we'll have, in that case, it doesn't matter if the class or method is final

yeah it would be actually very nice if the AOP attributes could be added on interface methods 👍

I like this. It's inline with the direction we took with attributes which is to reduce boilerplate around infrastructural concerns, simplifying configuration to allow focusing on business logic.

I do believe the PHP engine can improve the implementation by supporting hook calls for methods. I'm imagine something like this:

set_hook_func(Foo::class, 'barMethod', function (Closure $func, mixed ...$args) {
    // do something before or early return

    $result = $func(...$args); // call original or not

    // do something after

    return $result;
});

allowing full control over the func call:

• do something before (having the func arguments in the context, in case you want to manipulate them)
• call or skip the original func
• do something after (having the func "return value" in the context, in case you want to manipulate it)

then a proxy class won't be necessary and all limitations regarding inheritance will be gone \o/

I found two functions that closely match the expected behavior via uopz extension:

• https://www.php.net/manual/en/function.uopz-set-hook.php // Sets hook to execute when entering a function or method
• https://www.php.net/manual/en/function.uopz-set-return.php // Provide a return value for an existing function

but none of them allow you to call the original function dynamically, so they're limited to some specific use cases only.

@yceruto On this matter, you might want to take a look at the OpenTelemetry PHP Extension, which exposes a hook to wrap any calls, to trace it: https://github.com/open-telemetry/opentelemetry-php-instrumentation?tab=readme-ov-file#usage.

Still, it does not allow you to call the original function but you receive the related object, its params in the pre callback and the return value in the post callback.

thanks @gaelreyrol for the link, yes the thing is that if only one hook is allowed per function, we'll need full control over the func call so it can be wrapped into a set of interceptors with different targets (log, cache, transaction, etc.)

having pre/post hooks only will cover some cases, but still limited (e.g. not possible to skip the function call for caching interceptor, or manipulate the arguments before the call or the return value after)

we currently know exactly which methods will request interceptors, thanks to #[Attribute] and $builder->registerAttributeForAutoconfiguration(), and we can then compile a runtime artifact that sets up all hooks for those methods and the interceptors involved:

set_hook_func(Foo::class, 'barMethod', function (Closure $func, mixed ...$args) use ($interceptors) {
    return $interceptors->call($func, $args);
});

that way, devs won't have to deal with this high-level function but can work directly with their own interceptor adapter.

@ro0NL do you mean between the generated proxy and the targeted service? yes, if that's what you're referring to. Otherwise, no, it doesn't solve the whole problem as you need many interceptors for various methods and each method might be wrapped by multiple interceptors, and they shouldn't know about each other