Thanks for proposing and for submitting!

I'm wondering if we couldn't get rid of the interface and rename the proposed argument to e.g.AutowireInline?
To remove the interface, we could maybe make AutowireCallable extend AutowireInline.
Also, instead of a dedicated attribute for services built by factory, can't we add afactory argument to the AutowireInline attribute?

Thanks for proposing and for submitting!

I'm wondering if we couldn't get rid of the interface and rename the proposed argument to e.g.AutowireInline? To remove the interface, we could maybe make AutowireCallable extend AutowireInline. Also, instead of a dedicated attribute for services built by factory, can't we add afactory argument to the AutowireInline attribute?

Sure I was unsure about the naming anyway though 🙈.

About the interface:
Wouldn't it rather make sense to keep it to allow extending / allowing custom Attributes that may create definitions that could be used for the Autowiring to be handled?

I'd rather see it as a benefit there allowing one to implement the interface and go for it instead of extending the base classes like theAutowireInline (after renaming). Unless this may be undesired anyway 🤷. Just being curious here.

Combining the factory thing into theAutowireInline seems fine as well since both are inlined 👍.

I made the adjustments according to your comment unless the one with the Interface. Just let me know if I still should remove it / rename it or whatever 👍.

And thanks for your fast feedback on this!

I'm not convinced by the interface, I'd prefer removing it. I'm generally not convinced by interfaces for value objects and attributes are value objects. Extending the class makes sense to me in this case.

Alright 👍 I have removed the interface and based theAutowireCallable on the newAutowireInline as you proposed before.

Please update the PR description to show usages of the feature. This makes it a lot easier for the documentation team (and also for reviewers)

About my remaining concerns (ResolveNamedArgumentsPass,ResolveChildDefinitionPass and other pass not running), I'm wondering if we shouldn't add a newResolveAutowireInlineAttributesPass that would scan autowired services for this attribute and would register definitions for each of them. Then, based on some naming convention (likely built onContainer::hash($definition)),AutowirePass would just reference these definitions instead of callingAutowireInline::buildDefinition().

WDYT? Up to give it a try?

About my remaining concerns (ResolveNamedArgumentsPass,ResolveChildDefinitionPass and other pass not running), I'm wondering if we shouldn't add a newResolveAutowireInlineAttributesPass that would scan autowired services for this attribute and would register definitions for each of them. Then, based on some naming convention (likely built onContainer::hash($definition)),AutowirePass would just reference these definitions instead of callingAutowireInline::buildDefinition().

WDYT? Up to give it a try?

Sure!
Could you maybe give a few hints how / where to implement this correctly?
I'm struggling a bit with the input style and the expected outcome here and therefore maybe didn't understand what's really expected here.

Would you expect a definition be like this:

class AutowireInlineAttributesBar {publicfunction__construct(Foo$foo,string$someString)    {    }}class AutowireInlineAttributes{publicfunction__construct(        #[AutowireInline(AutowireInlineAttributesBar::class, ['$foo' => Foo::class,'$someString' =>'testString',        ])]publicAutowireInlineAttributesBar$inlined,    ) {    }}

Where the classFoo then would be a autowired as the provided service name and thesomeString injected as a string or what would you rather expect here to happen?

Besides that if I got you right I would have to create a class calledResolveAutowireInlineAttributesPass which then checks for a passedDefinition to be$definition->isAutowired() === true and check for it to have anyAutowireInline attributes to be processed (calling->buildDefinition(...) and registering those via$this->container->setDefinition(ContainerBuilder::hash($autowireInlineAttributeInstance), $definition);.

Is this assumption correct?

You've got it right I think :)

You've got it right I think :)

I've prepared something that doesn't quite work 🤷 as mentioned before maybe I'm missing something here. Could you maybe take a look so that we may correct the issues there or my misunderstanding 🙈?

I would be grateful 👍dd16390

@nicolas-grekas

Thank you@DaDeather.