In my opinion it's wrong to have bundles depend or use parameters that are not defined from within the bundle, this is exactly where the configuration comes into play. This is not a parameter but a configuration option for the DIC. The benefit of configuration is that you can enforce the format, whereas this allows users to get all kind of weird errors if the format isn't correct.

I would prefer to see something more like:

framework:autowiring-mapping:Psr\Log\LoggerInterface:my_logger

I agree with@iltar. Internally, such a config option could still just populate this parameter. But users should not have to rely on this implementation detail.

The downside with the config option is that it will not be available for people using the standalone component.

But, is this feature really necessary? Developers needing such tricks can already override the definition of the service and add theautowiring_types key.
IMO it's better to encourage developers to open PRs upstream to addautowiring_types than introducing such settings.

Btw, a new release of MonologBundle has been done and this fix isn't necessary anymore this specific case.

@dunglas Is there any "easy enough" way to override a service to do this - usinglogger as an example? I do it so rarely, I can't think of a pure config way (avoiding a compiler pass).

If there is an easy way, then maybe we can do that. Otherwise, I can follow the advice of the other guys and move it to config (I don't know why I didn't do that in the first place).

After talking with@wouterj, thereis a way (almost) to do this without needing new config. To continue with theLoggerInterface example (even though this problem is now fixed):

services:logger.for.autowiring:alias:loggerautowiring_types:            -'Psr\Log\LoggerInterface'

What do you think? It actually doesn't work now becauseAutowirePass doesn't look at alias services forautowiring_types (which could be considered a bug), but that can easily be fixed.

I much prefer this way.

that looks good, but what would happen with the following config?

# foo.ymlservices:logger.for.autowiring:alias:loggerautowiring_types:            -'Psr\Log\LoggerInterface'# bar.ymlservices:another.logger.for.autowiring:alias:loggerautowiring_types:            -'Some\Implemenation\Of\LoggerInterface'

@iltar with the current implementation, if you typehintSome\Implemenation\Of\LoggerInterfaceanother.logger.for.autowiring will be injected, and if you type hint the interfacelogger.for.autowiring will be.

The thing with the alias is exactly the same as what I originally proposed here#17783

@maryo I see that now - it's a clever solution, so I think it didn't "sink in" when you first mentioned it - sorry about that :)

Actually, this is a non-trivial solution to implement. The problem is that an "alias" service isn't represented as a full Definition object - it's just anAlias object:https://github.com/symfony/symfony/blob/master/src/Symfony/Component/DependencyInjection/Loader/YamlFileLoader.php#L179.

To supportautowiring_types no an alias service, we'd need to update every loader and add a new property toAlias so we know what types it should map to.

I was hoping the alias idea would be a nice "shortcut" so that we wouldn't need to add much/any code. But it's not. I recommend we use@iltar's original proposal:#18040 (comment)

Nevermind, I figured it out. It requiresno coding, and is pretty horrible-looking. But, it works (right now, today) and would require not coding. For example, if you assume still thatLoggerInterface could not be autowired, you could:

services:logger_for_autowiring:class:Psr\Logger\LoggerInterfacepublic:falseautowiring_types:            -Psr\Log\LoggerInterfacetags:            -{ name: auto_alias, format: 'logger' }

Yep, that does it - taking advantage of a little-known DI tag.

Should we just document this?

The funny thing is, I actually arrived on that page during the hack-day and I thought it wasn't what you were looking for :(

I think it would be an excellent idea to document the auto_alias option and refer to it in the auto-wire documentation. Imo would be best documented as "what to do when you want to autowire but symfony has no support for this case yet".

@weaverryan:
"we'd need to update every loader and add a new property to Alias so we know what types it should map to."
Yeah. I realized it too. I was not sure if it worth it or if there are better alternatives or a different proposals how such a feature should work or if it should be closed instead for some reason.
If only the amount of work was a problem then I could do it. I personally like it more than the parameter or config solution or even the auto_alias but thanks alot mentioning it is possible this way. I actually didn't know about this auto_alias feature.

What do others think? Maybe this workarround is acceptable because as Dunglas wrote "it's better to encourage developers to open PRs upstream to add autowiring_types than introducing such settings".
But maybe one could still need to set it to something else even it is already set (but maybe that could be considered as a bad practice and named services in such cases should be preferred).

I think for now, we should stick with this solution. If we find that we're using this a lot (and not just because there is some "bug" upstream that needs to be fixed), we can re-visit adding a clearer solution. But I feel pretty good that there's a workaround, and it's only a few lines of code (though a bit ugly)

I would like this feature as well. It's very counter intuitive and hard to understand. 5 lines is way too much for simpleclass/interface_type => service_name association.

I've added this feature to my bundle, so it's easy to use for everyone without deeper DI+yaml configuration knowledge:
https://github.com/Symplify/DefaultAutowire#multiple-service-of-one-type-set-preferred-one