Skip to content

[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

Merged
merged 1 commit into from
Jan 15, 2017
Merged

Conversation

nicolas-grekas
Copy link
Member

@nicolas-grekas nicolas-grekas commented Jan 12, 2017

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

@keradus
Copy link
Member

keradus commented Jan 12, 2017

http://symfony.com/doc/current/contributing/code/bc.html#changing-classes

Type of Change | Change Allowed
Make final | No

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 final by annotation is not a bc breaker in strict point of view, it makes it risky that one will break a BC in a future thinking his not doing that.

even if class will be deprecated a BC should not be broken.

@nicolas-grekas
Copy link
Member Author

We need ways to move forward with the code base. What would you suggest to allow this kind of moves? (See #20493 also)

@linaori
Copy link
Contributor

linaori commented Jan 13, 2017

@keradus it doesn't mention anything about generated classes. To be fair, you should probably not be extending generated code in the first place.

@dunglas
Copy link
Member

dunglas commented Jan 13, 2017

👍

@@ -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
Copy link
Contributor

@GuilhemN GuilhemN Jan 14, 2017

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)

Copy link
Member Author

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. :)

@xabbuh
Copy link
Member

xabbuh commented Jan 15, 2017

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 final by annotation is not a bc breaker in strict point of view, it makes it risky that one will break a BC in a future thinking his not doing that.

I do not understand your comment. The class will not be final in 3.4. We will only do that in 4.0. But the @final annotation will lead to people seeing a deprecation message starting with 3.3 when extending the generated class so they can actually prepare for the break in 4.0.

@xabbuh
Copy link
Member

xabbuh commented Jan 15, 2017

👍

Status: Reviewed

@nicolas-grekas
Copy link
Member Author

@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.

@fabpot
Copy link
Member

fabpot commented Jan 15, 2017

Thank you @nicolas-grekas.

@keradus
Copy link
Member

keradus commented Jan 15, 2017

it doesn't mention anything about generated classes. To be fair, you should probably not be extending generated code in the first place.

@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

@fabpot fabpot merged commit ce0ee1e into symfony:master Jan 15, 2017
fabpot added a commit that referenced this pull request Jan 15, 2017
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
@nicolas-grekas nicolas-grekas deleted the di-final branch January 15, 2017 16:06
@fabpot fabpot mentioned this pull request May 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants