-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[DI] Mark generated containers as final #21263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
http://symfony.com/doc/current/contributing/code/bc.html#changing-classes Type of Change | Change Allowed It's only annotation, but when one will remove protected property in 3.4 because he see that annotation he will think it's not a bc breaker. Then, even if this even if class will be deprecated a BC should not be broken. |
We need ways to move forward with the code base. What would you suggest to allow this kind of moves? (See #20493 also) |
e46451d
to
ce0ee1e
Compare
@keradus it doesn't mention anything about generated classes. To be fair, you should probably not be extending generated code in the first place. |
👍 |
@@ -805,6 +805,8 @@ private function startClass($class, $baseClass, $namespace) | |||
* | |||
* This class has been auto-generated | |||
* by the Symfony Dependency Injection Component. | |||
* | |||
* @final since Symfony 3.3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add a dot at the end to be consistent with @deprecated
? (Note that #20493 supports both syntaxes)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as #20493 is concerned, this shouldn't matter to me as DebugClassLoader should be able to deal with both situations. :)
I do not understand your comment. The class will not be |
👍 Status: Reviewed |
@xabbuh this comment was done before "since Symfony 3.3" was added; it's true that without this, it would have been too easy to wrongly believe that some class could be changed later on (say 3.4) while it weren't yet possible. |
Thank you @nicolas-grekas. |
@iltar , the thing was that not everyone will check if the class was autogenerated and if so, consider could he rely on it or not. better to be protective and prevent for that, right ? :) 👍 for PR |
This PR was merged into the 3.3-dev branch. Discussion ---------- [DI] Mark generated containers as final | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | yes | Tests pass? | no | Fixed tickets | - | License | MIT | Doc PR | - So that we don't have to care anymore about BC for protected methods in generated containers. Will leverage deprecations triggered in #20493 Commits ------- ce0ee1e [DI] Mark generated containers as final
So that we don't have to care anymore about BC for protected methods in generated containers.
Will leverage deprecations triggered in #20493