Any ideas on an instanceof tagged iterator? That would prevent the need for tagging these services first.

Any ideas on an instanceof tagged iterator? That would prevent the need for tagging these services first.

$container->registerForAutoconfiguration(YourInterface::class)
    ->addTag('your_tag');

$container->registerForAutoconfiguration(YourInterface::class)->addTag('your_tag');

💯

or #39804 on 5.3+PHP8 :)

This approach means that for arguments, we don't provide extensibility similar to registerAttributeForAutoconfiguration(). But maybe we don't need it. I can't think of an obvious use case anyway.

Me neither. I started using the same mechanism first, but I wasn‘t happy with it.

In the configurators, I always accessed the bindings, fetched the parameter name from the reflector, prepended it with a $, configured an argument object, added it to the bindings as stuffed the new bindings arrays back into the definition. This felt like a lot of unnecessary, error-prone boilerplate.

And in the end, constructing the argument object was the only operation that is different in each configurator. So my next attempt was to reuse an existing data structure for arguments and I somewhat liked who easy it was to implement that. But I already noticed that you‘re not sharing my enthusiasm here and that‘s fine. I‘m going to build dedicated attributes for constructor parameters. 🙂

What else should we support? I can think of:

• #[Value('%foo% bar %env(baz)%')]

Value is probably a good idea, though I‘d like to have simplified versions of it as well: Parameter and EnvVariable.

We could add a way to reference services by identifier, but I don't think it's a good idea, since autowiring provides better decoupling and the code should not know about service ids.

I don‘t think that it‘s inherently bad to have that attribute. However I can imagine more bad than good use-cases for it. But I‘ll leave it out of this PR for the moment.

Value is probably a good idea, though I‘d like to have simplified versions of it as well: Parameter and EnvVariable.

I'm mixed on this: it'd mean teaching something that would be a dead-end once ppl want to append/prepend any string next to a param/env. I think I'd prefer not to add them.

Please have another look. The PR now uses new dedicated attribute classes.

I've switched the pass to AbstractRecursivePass and added tests for a nested definition and a factory service.

(please rebase to account for #40468)

I have explored a bit if we can extend that feature to setters, but I'm a bit afraid of the edge cases that we get here.

Is the idea to browse all public methods for those attributes? If yes:

• If we find one of the attributes on a parameter of a public method other than the constructor: Do we add a method call for that method?
• What if there already is a method call configured for that very method?
• What if the method has more parameters than the one with the attribute?

Or should we only browse methods that are already configured to be called?

• What if a call is added later, via a userland compiler pass?
• Is this behavior comprehesible for a developer or would they expect the attribute to act as a marker for "call this method"?

I submitted derrabus#1 on your fork to help implement this in a simpler yet more powerful way.
The core idea is that this is a matter related to autowiring - not to autoconfiguration.
Once we acknowledge this, the implementation becomes simpler and more powerful, have a look.

The implementation in AutowirePass also hints about two improvements that we could make after this:

1. we could add a new attribute to tell where a decorated service should be injected when using decoration. The current logic in AutowirePass is a bit fragile (it can detect the injection point only when a single argument is compatible with the decorated class.)
2. instead of harcoding how TaggedIterator/TaggedLocator are wired, we can make this generic thanks to a new $container->registerAttributeForAutowiring() method.

Thank you @derrabus.

Can TaggedLocator get an attribute for property as well? It creates a problem when constructor promotion is used:

Example:

    public function __construct(
        #[TaggedLocator(tag: 'app.tag')] 
        private ServiceLocator $locator,
    )
    {
    }

works but psalm reports this error:

This attribute can not be used on a property (see https://psalm.dev/242)

#[TaggedLocator(tag: 'app.tag')]  private ServiceLocator $locator,

Simple fix:

#[\Attribute(\Attribute::TARGET_PARAMETER | \Attribute::TARGET_PROPERTY)]
class TaggedLocator {}

Does it work? If yes, that's a bug in psalm where it should be reported.