One can define an interface within their application's domain to achieve better type-coverage without any new coupling.

Since the use-case is well-known, this interfaces should be provided by the FrameworkBundle itself. Otherwise the DX is broken as you don't have the signature of the closure for auto-completion and static analysis.

Continuing in this logic, having an invokable class for each helper would be more transparent: unique type for DI of each helper and method signature to call them. Less magic with the AutowireMethodOf attribute.

namespace Symfony\Bundle\FrameworkBundle\Controller\Helper;

class Render
{
    // Explicit dependency injection
    public function __construct(private Environment $twig) {} 

    public function __invoke(string $view, array $parameters = [], ?Response $response = null): Response
    {
        // ...
    }
}

So there is no need to use the magic attribute.

use Symfony\Bundle\FrameworkBundle\Controller\Helper\Render;
use Symfony\Bundle\FrameworkBundle\Controller\Helper\RedirectToRoute;

class MyController
{
    public function __construct(
        private Render $render,
        private RedirectToRoute $redirectToRoute,
    ) {
    }

    // Same function showProduct
}

I agree with Jérôme. I wouldn't want to see code using ControllerHelper elsewhere than in a Controller, even though it's only about pointing #[AutowireMethodOf] it feels just wrong conceptually.
So I'd either add as many high-level helpers as AbstractController methods in their respective components as suggested or keep things as they are today.

@GromNaN thanks for the comments. This proposal is about providing innovative ways to decouple from helper classes, with AbstractController and entity repositories as primary use cases.

Personally, I don't think maintaining a myriad of helper classes will improve anything: from a maintainer's perspective, it's an explosion of class, and from a DX perspective, it's a discoverability nightmare. Having one compact class with helper methods has been the natural solution for these reasons. This PR doesn't try to disrupt this practice - that's its main point and benefit: providing a solution to granularity without forcing us to use patterns that'd lead to even more classes/files to jungle with.

(Ignoring the likely too high migration costs, I think AbstractController could be favorably deprecated in favor of ControllerHelper, regardless of considerations related to AutowireMethodOf.)

If all the helper classes are in the same namespace, there is no discoverability issue.

The solution you propose is a less practical than the current AbstractController:

• You don't know the method signature, and you don't have any easy access to the method (until IDE/tools add support for introspection of AutowireMethodOf). It feels like magic __call.
• You have to repeat #[AutowireMethodOf(ControllerHelper::class)] private \Closure $<method> for every helper you want to use.
• The PHP syntax for calling a closure from a property is unusual ($this->redirectToRoute)('product_list').

The advantage of the closure is for mocking, but as soon as you add invokable interfaces you lose this advantage.

If all the helper classes are in the same namespace, there is no discoverability issue.

Typing $foo-> and seeing the possibilities is way more DX-friendly than having to see sibling classes in a folder/namespace.

The solution you propose is a less practical than the current AbstractController: [...]

I 💯 agree with you, those drawbacks are real (except the use of the "magic" adjective to highlight that you don't like it - any attributes can be described as such by nature of declarativeness - until the behavior is accepted, so that's not really helpful...).

Yet, all these drawbacks apply to AutowireMethodOf.
And the proposal is about ControllerHelper ;)

What I wrote in the PR description needs some visionary thinking: from an architectural PoV, the design that's allowed by AutowireMethodOf is far superior. The good thing about the drawbacks is that they all can be removed by improving either the tooling or the syntax. We're here to build the future - we're not bound by the current state of the art.

(If you don't share the vision completely, then you can focus on the meat of the proposal: ControllerHelper is already an improvement over AbstractController, eg it can be used with invokable controllers.)

The advantage of the closure is for mocking, but as soon as you add invokable interfaces you lose this advantage.

You don't, anonymous classes to the rescue.

For even better type-safety and application-level contracts, #[AutowireMethodOf] can generate adapters for functional interfaces. One can define an interface within their application's domain to achieve better type-coverage without any new coupling:

Why don't we create interfaces for those helper methods then and make those autowirable?

This is how I would approach all these questions and concerns, and then you decide.

Typing $foo-> and seeing the possibilities is way more DX-friendly than having to see sibling classes in a folder/namespace.

We need to consider the audience of this feature. Are the same people who care about decoupling also comfortable discovering through namespaces? Likely.

ControllerHelper is already an improvement over AbstractController, eg it can be used with invokable controllers.

Nothing prevents Symfony from offering this new option, see how people use it, learn, iterate. It's definitely an improvement, so it's worthwhile.

from a maintainer's perspective, it's an explosion of class

That's a very important consideration and I agree that maintainers should not be asked to bite off more than they can chew.

Why don't we create interfaces for those helper methods then and make those autowirable?

That is best for long-term maintenance of an app, if you want to be able to keep up with upgrades and BC breaks. We shouldn't inject interfaces we don't own into our controllers. With that in mind, the proposed solution makes it easier for devs to create the individual adapters which implement those interfaces.