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 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 inspection 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.

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?

A couple of thoughts I had on this topic:

• First, these type guarantees are not needed for many projects, so that this concern might be seen as overhead for some.
• From a design perspective, having the interfaces being owned by the app rather than the framework is the highest form of decoupling. This applies here because contrary to many other interfaces provided by the framework, the one we're talking about don't really serve as abstractions to me. They'd be just some type-coverage helpers.
• This lead me to wonder if local type aliases wouldn't be the correct solution to this problem - we could declare @phpstan-type on ControllerHelper and users would then @phpstan-import-type Render from ControllerHelper e.g. Of course that wouldn't help for autowiring.
• In any way - last but not least - this is a nice domain to explore after this PR ;)

Hi,
is there a benefit to use this construction

class MyController
{
    public function __construct(
        #[AutowireMethodOf(ControllerHelper::class)]
        private \Closure $render,
        #[AutowireMethodOf(ControllerHelper::class)]
        private \Closure $redirectToRoute,
    ) {
    }

    public function showProduct(int $id): Response
    {
        if (!$id) {
            return ($this->redirectToRoute)('product_list');
        }

        return ($this->render)('product/show.html.twig', ['product_id' => $id]);
    }
}

instead of this construction?

class MyController
{
    public function __construct(
        #[Lazy]
        private UrlGeneratorInterface $urlGenerator,
        #[Lazy]
        private TwigHelper $twigHelper,
    ) {
    }

    public function showProduct(int $id): Response
    {
        if (!$id) {
            return new RedirectResponse($this->urlGenerator->generate('product_list'));
        }

        return $this->twigHelper->render('product/show.html.twig', ['product_id' => $id]);
    }
}

There are some methods which only forward theirs arguments to a service like generateUrl, isGranted, createForm, createFormBuilder, getUser, isCsrfTokenValid and those can be replaced by lazy services.

Separate helpers (for better decoupling) can be created for other methods: TwigHelper::render(), HttpHelper::forward(), SecurityHelper::denyAccessUnlessGranted(), ...

If necessary, RoutingHelper::redirectToRoute() can be created.

This approach is more straightforward. In addition, it offers this use.

class MyController
{
    public function showProduct(
        #[MapEntity(id: 'id')] Product $product,
        RouteHelper $routeHelper,
        TwigHelper $twigHelper,
    ): Response {
        if (!$id) {
            return $routeHelper->redirect('product_list');
        }

        return $twigHelper->render('product/show.html.twig', ['product_id' => $id]);
    }

    public function deleteProduct(
        #[MapEntity(id: 'id')] Product $product,
        SecurityHelper $securityHelper,
        // ...
    ): Response {
        $securityHelper->denyAccessUnlessGranted('delete', $product);
        // ...
    }
}

@ludekbenedik sure, that's another possible follow up of this PR. Yet, it's not the one I'd push for personally, here is why:

• It still builds on coupling: those classes would be in the Symfony namespace and wouldn't be abstract.
• It still builds on inheritance, just elsewhere: the new helpers would need to be inheritable to still provide extensibility (to make the coupling not a hard one).
• From a DX PoV, it'd make things harder, because discovering a class somewhere deep in a namespace is way harder than discovering a method in a helper class. That's the very reason why this helper has been created: yes, some methods are proxies - and the only reason why they exist is that: improved DX by discoverability. Let's not dismiss this aspect of the current state.
• From a maintainers PoV, splitting helpers in many classes will just increase the maintenance surface while all the previous items already make them meh.

We can alleviate the first 2 items by introducing interfaces, but that'd weaken the last 2 items to me. Also I don't think it makes sense to introduce interfaces for that, the reason being that helpers are not abstractions per se.

From a design perspective, having the interfaces being owned by the app rather than the framework is the highest form of decoupling.

Right, but effectively Symfony owns the signatures of those helper methods. Telling app developers to provide their own interface which contains a copy of our signature, looks the same on every project and and has to be kept in sync after updating Symfony, does not change that.

This applies here because contrary to many other interfaces provided by the framework, the one we're talking about don't really serve as abstractions to me.

Of course not. All those helpers simply hide some commonly used glue code which is why I wanted to solve it with traits back then.

The ship has sailed for the traits option - it suffers from difficult DI + files/traits explosion ;)

You're right about app-owned interfaces, but only to a certain degree: it would always be possible for an app to write their own adapters if the ones generated by the DIC don't fit. Yes, that might be some work, but that's what e.g the DDD folks would aim for: being the ones in full control of boundaries.

Note that I'm not telling that every apps should do it this style - like I'm not telling anyone DDD is the only possible approach to software design. But it's still nice to draw a path forward that goes in the direction of more advanced SOLID software.

Personally, I think I'd first stop at the AutowireMethodOf + Closure style and then I'd try to improve the tooling so that static analyzers understand how types should be interpreted. It should be possible to create an implicit type from such arguments that'd forward the signature of the target method to callers of the closure, and to callees of the constructor.
And for IDEs, I'd like to see autocompletion when the $ is typed for that argument.

I might also seek for a syntax that removes the need for repeating AutowireMethodOf. JavaScript has "import foo, bar from Baz". Maybe something like that written using an attribute on the constructor or the class itself. For a future PR :)

Let's settle on the PR as is?