Define alias with an attribute

[garak]

Description

Scenario: you have a concrete class that implements an interface. Currently, you need to add an alias in your services configuration,
The idea is to avoid it with a new php8 attribute, that can be applied to the class.

Example

<?php

namespace Foo;

use Symfony\Component\DependencyInjection\Attribute\Alias;

#[Alias]
final class MyClass implements \Bar\MyInterface
{
    // ...
}

the following then can be avoided:

services:
    Bar\MyInterface: '@Foo\MyClass'

[nicolas-grekas]

This issue with this approach is that many classes can have the attribute, which will create collisions.
Also, the class might implement many interfaces. Which ones should be aliased?
Maybe all these questions mean that the attribute should be on the interface instead.
Or how would you solve these concerns?

[garak]

We could ask for a mandatory parameter in case of multiple interfaces.
About the possibility of collisions, I guess that it already exists now (I hope it's handled by container).
I don't like the idea of putting annotation on the interface itself, since it can be out of your control

[nicolas-grekas]

About the possibility of collisions, I guess that it already exists now (I hope it's handled by container).

Actually not, there is no need for such a mechanism currently as no collision can happen, since only one service or alias can be named "foo".

I don't like the idea of putting annotation on the interface itself, since it can be out of your control

Can you review actual use cases of yours and give us some examples where such aliases are need, both when you have control over the interface, and where you don't?

Because putting the alias on the interface would really be the most appropriate.

Maybe we can accept that when you don't have control over the interface, you should/could not use the attribute?

[garak]

About the possibility of collisions, I guess that it already exists now (I hope it's handled by container).

Actually not, there is no need for such a mechanism currently as no collision can happen, since only one service or alias can be named "foo".

Indeed, in yaml it's impossible just because you can't use the same keys twice.
But I just tried with PHP configuration:

<?php
return static function (ContainerConfigurator $configurator): void {
    $services->alias('foo', MyClass1)->alias('foo', MyClass2);
}

And it's allowed: the first alias is overwritten by the second one.

Can you review actual use cases of yours and give us some examples where such aliases are need, both when you have control over the interface, and where you don't?

The typical use case is when the interface is in a vendor.
But also when it's under my control, in my typical project (using DDD) I keep interfaces in the Domain layer and concrete classes in the Infrastructure layer: adding annotations in the former is wrong, because service definitions belong to the latter.

[HypeMC]

Because putting the alias on the interface would really be the most appropriate.

There's also the case when the alias is not an interface, but a arbitrary string. This and then case when you don't have control over the interface make me think it's better to use this attribute on a concrete implementation since you can't cover every case on the interface. You could make this attribute work on both interface and classes to cover this cases, but that makes the usage inconsistent IMO.

[nicolas-grekas]

Closing as discussed in #41207

[nicolas-grekas]

See #49361