Hey!

I think@fractalzombie has recently worked with this code. Maybe they can help review this?

Cheers!

Carsonbot

I like this idea but what about binding services as well? I'm thinking just a singleBind attribute:

class DummyService{publicfunction__construct(        #[Bind('@another.service.id')]publicAnotherService$service,        #[Bind('%kernel.debug%')]publicbool$isDebugEnv    ) {    }}

This would be a shortcut to the following (which is possible now):

#[Autoconfigure(bind: ['$service' =>'@another.service.id','$isDebugEnv' =>'%kernel.debug%',])]class DummyService{publicfunction__construct(publicAnotherService$service,publicbool$isDebugEnv)    {    }}

I like this idea but what about binding services as well?

Isn't it already solved in some way with theTarget attribute (which relies on named autowiring aliases rather than on service ids) ?

Isn't it already solved in some way with the Target attribute (which relies on named autowiring aliases rather than on service ids) ?

Partially, but not for service ids themselves and this was what I was looking for. I'm envisioning this purely as a short-hand forAutoconfigure(bind).

The reason I did not consider it for services is that services are already automatically injected on top of already having theRequired attribute docblock annotation and the{with,set}Something methods as well. For services which have ids rather than the FCCN I figured one of the existing solutions could be used instead.

The other thing is that this accepts only parameters rather than a string with a parameter in it such as%param%/some_string. For this, I figured since this is right next to the constructor, the concatenation could be done there. The other reason being that#[Parameter('kernel.debug') looks "cleaner" than#[Parameter("%kernel.debug%")], but something like#[Bind("%kernel.debug%"]) also has its merits. Both syntaxes are fine by me so we can go with whichever is more suitable to the project.

The reason I did not consider it for services is that services are already automatically injected on top of already having the Required attribute docblock annotation and the {with,set}Something methods as well. For services which have ids rather than the FCCN I figured one of the existing solutions could be used instead.

Yes, this would just be a shortcut forAutoconfigure(bind: ...). There is no other way to configure service id's (that I'm aware).

Recently I also became aware of the #[Autoconfigure(bind:['$isDebugEnv' => '%kernel.debug%'])] syntax. This addresses the separation of the declaration into multiple files and follows the class when moved around. If this PR won't pass then this would be our preferred method once the application I help develop is upgraded to PHP 8.

• The argument name is passed as a string to bind and is also not refactored and is also duplicated.
• Can only be applied to a class rather than the constructor, having argument names and the constructor be visually "far" from each-other.

To me, this argument applies to binding services as well as parameters.

parameters rather than a string with a parameter in it such as %param%/some_string

SinceAutoconfigure(bind: ...) supports this, I believe the parameter attribute should as well.

Based on the various comments here, I think there is a misunderstand about whatAutoconfigure(bind: ...) is doing.

theAutoconfigure attribute is not about replacing file-level default bindings. It is about registering a type into the autoconfiguration system (seeContainerBundler::registerForAutoconfiguration) so that all services being of that type will be autoconfigured with that rule (if they have opted-in for autoconfiguration)

So to clarify, for my second code blockhere. This would register the$service binding globally (not just in this file)?

Looking at#39804.

This should typically be added on a base class/interface to tell how implementations of such a base type should be autoconfigured.

Indeed, this was a misunderstanding on my part.

So what I'm looking for and I believe@maldoinc is looking for (for parameters at least) is a way to take this config:

services:App\SomeService:        -'@some.other.service'        -'%some.parameter%'

And use constructor parameter attributes to configure:

class SomeService{publicfunction __construct(        #[???('some.other.service')]        public AnotherService $service,        #[???('some.parameter')]public string$parameter    ) {    }}

@kbond the Autoconfigure attribute would register a binding applied on all (autoconfigured) service whose class is a DummyService or a child class of DummyService

Thank you@maldoinc for this PR. I'm closing it because we figured out another attribute would be more generic. See#45657, you might like it.