We can also imagine automatically determine the service corresponding to a controller.

This is one of the cases where I actually think this would be very beneficial. The SensioFrameworkBundle could then add support for @Controller() which would simply check for ->has(get_class($controller)). This would remove the "tight coupling" between class and service.

Would that means the "class" key can be omitted if class_exists($serviceName)?

services:
    Foo\Bar: ~
    Bar\Baz: ~

/** 
 * @Controller() 
 */
class Foo\Bar
{
    public function __construct(Bar\Baz $baz) {}
}

Note that my wish is to rename the @Route in the extra bundle to @Controller, not possible yet.

@iltar actually, the call would be ->getServicesIdOfType(get_class($controller)) (except if we had a new method hasOfType ?)

And I like your idea but we have to investigate a bit more to see if it wouldn't create BC breaks/weird behaviour.

anyone else review about this ? I'd like to know if this would be accepted or not before finalizing it (or if you prefer #18268).

I think it's a nice improvement.

Adding these methods to the ContainerBuilder class might be useful to make some compiler passes easier to implement. However, I am not convinced that we should add them to the Container class too. I guess that this would make people tend to use the container in a way they shouldn't do.

@xabbuh this is useful to find services implementing a class at runtime, especially for controllers.

@Ener-Getick and what if you make it like this:

services:
    Foo\Bar: ~
# same as, except that the key is the class name in the first example
services:
    foo.bar:
        class: Foo\Bar

That means you can do $container->get(Bar::class); which should be validated compile time.

@iltar this is not the issue solved by this PR, maybe I wasn't clear in its description.
The goal here is to create a link between services and classes.
For example if you have these services:

services:
    app.foo:
        class: Foo

    app.bar:
        class: Bar # extends Foo

You can use this:

$container->getServiceIdsOfType(Foo::class);
// will return ['app.foo', 'app.bar']

$container->getServiceIdsOfType(Bar::class);
// will return ['app.bar']

IMO this should not be used in a traditional app but it is useful for compiler passes or for classes needing to be very flexible (like the ControllerResolver).

@xabbuh IMO we should keep at least getServiceIdsOfType in the Container, I agree that the other methods could introduce bad practices...

Regarding the Controller Resolver, I'm working on deprecating the current method by introducing a factory (similar to the argument resolver).

@xabbuh I removed the new methods of the Container for now ; I think we'll see later if we really need them by testing this feature.

I'm 👎 about this feature. It adds a new way to do what already can be done and I don't feel the new way is better.

First, as explained by @Ener-Getick, this will throw exceptions in some cases because services don't have a one-to-one correspondence to classes (e.g. Doctrine repositories defined as services share the same class).

Second, this is more complicated to explain. E.g.

Before: if you want to get the main Doctrine service to access the different entity managers, just get doctrine service:

$this->get('doctrine')->...

After:

use Symfony\Bridge\Doctrine\RegistryInterface;

$this->get(RegistryInterface::class)->...

What's a registry? Why the interface? Why it doesn't include the Doctrine word anywhere? Why the ::class when I want to get a service? How can I discover that to get doctrine I need to use RegistryInterface?

I have the same feeling as @Ener-Getick. Since the landing of auto-wiring, I'm not comfortable with all the features that are proposed, they are quite far from the overall philosophy of the DI component, which has always favored explicitness.

I'm also 👎

@javiereguiluz @fabpot and what do you think about the proposition of @xabbuh which is mainly meant to be used internally (only available at compilation)?
This is in fact only a move of the logic from the AutowirePass to the ContainerBuilder.

An example of how to use it:

$container->register('foo', 'Foo');
$container->register('bar', 'Bar'); // subclass of Foo

$container->getServiceIdsOfType('Foo');
// will return ['foo', 'bar'] 

$container->getServiceIdsOfType('Bar');
// will return ['foo'] 

It would only be possible to get the service ids of a certain type that way not their instance.

The last commit uses \SplObserver and \SplSubject but it seems to me to be too much complex for the initial goal...
Maybe it would be easier/better to only create an utility class as initially proposed by @dunglas.

After thinking, I created the utility class @dunglas proposed. This is much easier to maintain and to understand as we don't have to worry about definitions changes.
I doesn't like really much its name (I called it ServiceTypeHelper), maybe someone has a better idea?

@Ener-Getick The instance of ServiceTypeHelper could be shared. I want to use it in #18268 (or in a library based on #18268).

@hason it's complex to share it as we have to reload the map each time a definition changes which is complicated to know (you can see my first try).
This is much easier to create the map each time we need it (and could be optimized with a static variable registering all the types corresponding to a class).

Something else that might be useful with something like this, is resolving the validator that belongs to a constraint. Right now you have to add a service id, but this could in theory be easy to resolve based on the class name, similar to form types.

@iltar only if we allow this to be used at runtime (the current state is a class only available when compiling).

Closing for now as it needs changes to work with the last changes.

This would be really great, as it's autowiring by types is already present in the core.

@TomasVotruba i agree but that's a big task and we have several ways to do it that all have benefits and disadvantages. I don't think i'll have the time to take a look at it again soon but maybe in a month or two i'll be able to reopen a pr :)

@Ener-Getick Thank you for your persistence and work on this 👍. It's very difficult to make a mind-shift from named services to typed services.

I'm starting something similar via external bundles. So it's optional and easy to integrate and test proof of concept:

• https://github.com/Symplify/ControllerAutowire
• or less stretched: https://github.com/Symplify/ActionAutowire

For you first example, you can take a look at DunglasActionBundle which does more or less the same thing but also applied to other part of the framework (commands, event subscribers, etc), the other one looks a bit redundant with the other one (and a bit more hacky).
Anyway, having a map translating classes to services name would be awesome in this context :)

I know that bundle, but it does too much. I really need only the autowiring on controllers. Also didn't work on first use.

The ActionAutowire is less clean, yet on half way to constructor injection. Rather see explanation here http://www.tomasvotruba.cz/blog/2016/09/19/how-to-get-more-than-request-in-controller-action/

@TomasVotruba @Ener-Getick You can use https://github.com/symfonette/class-named-services library.

@hason this pr is for compile time whereas yours is for runtime, so that's not the same kind of use :)

@GuilhemN Btw, do you have your utility class somewhere available as package? Would love to try it.

@TomasVotruba no, but you can extract it from this PR if you want.

@GuilhemN Sure, just prefer reusable open-source code.

@TomasVotruba i understand, i'll reopen this pr for 3.3 when 3.2 will be released.

see #20940