I'm still not a fond of having (non-standard) annotations for DI. I've explained my reasons in depth here:#21103 (comment)

However I recognize that it is practical for parameters injection. I've proposed a less intrusive alternative in#20738, but I'm not very convinced by it either.

Maybe should we keep with the current solution for now:

_defaults:autowire:trueparameters:mandrill_api_key:XXXXXXXXXservices:App\NewsletterManager:['', '', '%mandrill_api_key%']# This is already working

@dunglas :

services:App\NewsletterManager:['', '', '%mandrill_api_key%']# This is already working

This is not already working, until#21313 is merged 😄

@dunglas I agree with much of what you are saying :), and I see that we're both after trying to solve the "parameter" problem in some decent way. I'm also not convinced by#20738, so we could either stay with the current YAML solution or use annotations (or maybe there's a 3rd option). About your comments (#21103 (comment)), I don't see these as a significant problem. Overall, the fact that this feature would be meant for end-users - and not library authors - puts most of those concerns to rest. And in app code, coupling your code to your framework isn't a problem (actually, I see it as an advantage for speed and clarity). Also, it mayhelp the container to be seen as simply an "internal detail" to end-users. If auto-wiring were perfect, then life would be good. But since there will always be edge-cases (parameters being the big one), with annotations, the user could avoid needing to suddenly (and strangely) go intoservices.yml and add a service key + arguments key (e.g. where the first two args are empty strings). Instead, they would just annotate one arg in their class :).

But, we'll see what others think - I wanted to get some real code to help with this exact discussion!

Cheers!

For me, the BIG motivation is to augment autowiring, when you have just one argument that can't be autowired. Annotations read much better than, for example, setting the index "2" argument in YAML.

This made me think, can't we have named arguments in yaml? (e.g.

services:Foo:arguments:mandrillApiKey:%mandrill_api_key%

).

Having annotations look huge to me if this is the only motivation, don't you think ?

@GuilhemN I've proposed this exact solution to@nicolas-grekas today and I'm working on a PR to implement it 🙌

@dunglas@GuilhemN I don't think I agree with that approach, as it's unexpected that changing argument names would have a side effect (this is true with annotations too, but at least the annotation & arg name are together). But, let's open that PR and decide the best solution!

Alternative proposal:#21383

Note that to me, this PR and#21383 do not compete. We could very well have both onboard.

I'll close this for now (thanks to#21383). We may still want this in the future, to avoid needing to touch a YAML file once you need to map a custom, non-autowired arg... but let's see how this all sorts out.