[DI][DX] Do not map id to class for global classes #21453
Conversation
|
👍 looks sensible to me |
|
👍 |
| /** | ||
| * @dataProvider provideInvalidClassId | ||
| */ | ||
| public function testWontResolveClassFromId($serviceId) |
There was a problem hiding this comment.
is it a Symfony convention to put the providers before the test method? (I personally tend to put them all as the last ones)
There was a problem hiding this comment.
Actually, the Symfyon "convention" is to put the provider just after the test using it.
There was a problem hiding this comment.
It's a personal preference. I prefer showing the dataset before the testcase itself, as I find it more readable like this (the test case might be long, so having the dataset right before the method allows to quickly see the tested data, whereas having it after the method may not fit your screen). It's totally arguable.
Should I change that?
There was a problem hiding this comment.
As this is Symfony code, there is personal preference, but consistency with the code base. So, I would indeed change that.
There was a problem hiding this comment.
Fair enough :)
Done.
|
Thank you @ogizanagi. |
…anagi) This PR was merged into the 3.3-dev branch. Discussion ---------- [DI][DX] Do not map id to class for global classes | Q | A | ------------- | --- | Branch? | master | Bug fix? | yesish | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #21380 | License | MIT | Doc PR | N/A Using a global classname as service id without specifying the definition class attribute won't work anymore after this, in the benefit of properly throwing an exception at compilation time for a misconfigured service. Service ids could previously be wrongly interpreted as a class name. So: ```yml services: app_bar: arguments: ['foo'] ``` will now properly result into: > Fatal error: Uncaught Symfony\Component\DependencyInjection\Exception\RuntimeException: The definition for "app_bar" has no class. at compilation time. Commits ------- bb87030 [DI][DX] Do not map id to class for global classes
Using a global classname as service id without specifying the definition class attribute won't work anymore after this, in the benefit of properly throwing an exception at compilation time for a misconfigured service. Service ids could previously be wrongly interpreted as a class name.
So:
will now properly result into:
at compilation time.