Recommend using the FQCN as a service ID

[greg0ire]

In most cases, service definitions live in the same root namespace as
the class they use.
I think this rules dates from before autowiring, and made some sense at
that time because you wanted people to name their services
guzzle.http_client rather than http_client, which would have caused
collisions. Now, the possible collisions come from far less likely
scenarios where a bundle defines a service from another bundle, and can
be solved by requiring the prefix only for those. Likewise, if a bundle
needs to define several services from one class, they should use the
prefix (since they cannot use the FQCN anyway). Finally the paragraph
below recommends to create an alias from the interface/alias to the
service id. That's a risk of collision, and if it is acceptable, then
this change is acceptable too IMO.

[linaori]

I do not agree with this. If 2 bundles use the same Symfony class, there would be a service ID collision which neither can solve and will cause problems.

For re-usable bundles I would suggest to simply use a bundle prefix (IltarHttpBundle -> iltar_http) that matches the extension prefix. That way every service id will be unique. Interface aliases can also cause this problem, so it should be used with caution. Yes I know this is not autowire friendly, but it's the most robust solution.

That said, if it's for your own library or not an external package, feel free to do as you like.

[greg0ire]

That said, if it's for your own library or not an external package, feel free to do as you like.

That's the whole point of this PR, this is by far the most common use case in my experience.

[linaori]

That said, if it's for your own library or not an external package, feel free to do as you like.

That's the whole point of this PR, this is by far the most common use case in my experience.

Is it an idea to document both use-cases? It's an edge-case, but imo worth documenting.

[greg0ire]

Maybe I should phrase it better, but yeah, I want to document both cases : owning the class or not

[juliendufresne]

To sum up in different words

Services that refers to classes defined inside the bundle should use the FQCN.
When the service refers to a class defined outside the bundle should use the bundle prefix.

But having two scenario is confusing and is not easy to remember.

[linaori]

But you have different scenarios and not doing it right, will introduce hard to trace bugs.

[greg0ire]

The second paragraph says "For public services,
:ref:aliases should be created <service-autowiring-alias> from the interface/class
-to the service id."

So if I understand this correctly, you should end up with

my_bundle.some_hopefully_meaningful_string:
    class: Vendor\MyLib\SomeNamespace\SomeClass

Vendor\MyLib\SomeNamespace\SomeClass: '@my_bundle.some_hopefully_meaningful_string'

This means that you would end up with 2 names for the same service, it also means that you still can have collisions between aliases, so it re-introduces the issue the first paragraph aims to solve, and in addition, the first name is error-prone, often simply derived from the class name, and can lead to more copy/paste mistakes IMO. This PR proposes to simply drop the less reliable of the 2 names when possible. Fewer names means fewer hard to trace bugs, I think.

Doesn't this look easier not to mess up?

Vendor\MyLib\SomeNamespace\SomeClass: ~

This would have the additional benefit to draw more attention to special cases when they occur.

[greg0ire]

I talked about this with @nicolas-grekas last week, and he told me using FQCNs would pollute the debug:container --types list with things that might be irrelevant to the end user.

[nicolas-grekas]

💯 bundles should keep using non-fqcn service IDs, which means no autodiscovery. They should also not use autowiring nor autoconfiguration. The reason is that by doing so, they would impose an overhead on the compilation steps (loading PHP code is slow on the CLI where OPcache can't leverage shared memory.)

[greg0ire]

👍 I might change this PR later to add your comment as a side note