Autowire ServiceLocator with iterable of tagged services #39924
Comments
Best case would be to allow interface usage instead of string-based tag names: class MyService
{
public function __construct(
#[TaggedInterface(FormTypeInterface::class)] private ServiceLocator $tagged
) {}
/**
* @param class-string<FormTypeInterface> $className
*/
public function get(string $className): FormTypeInterface
{
return $this->tagged->get($className);
}
}
$formType = $myService->get(EntityType::class); A feature like this could be useful for a day we get generics; tools like rector might provide automigration: public function __construct(private ServiceLocator<FormTypeInterface> $tagged) |
This looks like just one step after #39897 - could happen in 5.3 :)
I would clearly advise against this. It's a shortcut that forgets that tags are absolutely required as intermediaries to create collections of services in a decoupled way. But fortunately, together with #39804, you might end up being able to provide a very similar DX. |
That is OK. My tagged services have same name as interface i.e. $container->registerForAutoconfiguration(ExporterInterface::class)->addTag(ExporterInterface::class); so I thought to maybe even remove this one line. But yes, it might be too much, sorry. |
PR welcome @zmitic |
@nicolas-grekas For If so; would I be allowed to create another class instead of |
For |
Description
Use attributes to have autowiring between ServiceLocator and tagged services, by key that can be either FQCN (default) or allow users to define it. Upgrade of implementation: #29203
Example of FQCN index, along with psalm annotation use:
If users want different index (like #29203), optional parameter would be the name of static method used:
If of any relevance, stub for ServiceLocator can be this:
The text was updated successfully, but these errors were encountered: