Skip to content

[TwigBridge] fix FormExtension::$renderer bc break #20710

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

Closed
wants to merge 1 commit into from
Closed

[TwigBridge] fix FormExtension::$renderer bc break #20710

wants to merge 1 commit into from

Conversation

fbourigault
Copy link
Contributor

Q A
Branch? 3.2
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? yes?
Tests pass? yes
Fixed tickets N/A
License MIT
Doc PR N/A

Before b515702, the FormExtension::$renderer property was not declared but initialized in FormExtension::__construct(). This makes the property visibility to public. In b515702, the property was declared but with a private visibility. This broke the backward compatibility of the
FormExtension class.

    Before b515702, the FormExtension::$renderer property was not
declared but initialized in FormExtension::__construct(). This makes the
property visibility to public. In b515702, the property was declared but
with a private visibility. This broke the backward compatibility of the
FormExtension class.
/**
* Make this property private in 4.0.
*/
public $renderer;
Copy link
Contributor

@greg0ire greg0ire Dec 1, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a better way might be to keep it private and use a magic getter to throw a deprecation notice? I know, magic is bad, but deprecation notices might outweight this?

Copy link
Contributor Author

@fbourigault fbourigault Dec 1, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea but how to avoid access to properties other than $renderer in a nice way? Throwing a RuntimeException? And what about __isset and __unset ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd indeed throw an exception. And yeah, __isset and __unset would have to be implemented, so… not sure it's worth the hassle.

@@ -23,7 +23,10 @@
*/
class FormExtension extends \Twig_Extension implements \Twig_Extension_InitRuntimeInterface
{
private $renderer;
/**
* Make this property private in 4.0.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please mark it as @internal though, so that IDEs warn users

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw, no need to mark it as private in 4.0, as it will be removed.

@stof
Copy link
Member

stof commented Dec 1, 2016

I'm not even sure this will solve your issue, as I don't think the property is initialized anymore in core (due to deprecation)

@fbourigault
Copy link
Contributor Author

You are right. Is adding re-adding the dependency as lazy to avoid the circular reference problem fixed in b515702, removing the deprecated notice from the constructor (I think Symfony should not trigger deprecated when using own objects) and using magic methods with deprecation notice will solve the issue?

@stof
Copy link
Member

stof commented Dec 1, 2016

Note however that I'm not sure this should be actually fixed. A property not defined in the code cannot really be considered as being part of our public API covered by the BC promise (and if it had been declared explicitly previously, it would have been tagged as @internal btw, excluding it from the BC promise).

@fbourigault
Copy link
Contributor Author

I understand that the missing property was a mistake and if it existed, it will never been with a public visibility, but at least one bundle (sonata-project/SonataAdminBundle#4216) was using it. As sonata-project has a BC release process, it may be ok to not fix it in Symfony, but it may have other libraries relying on this public property (I don't have any example).

@stof
Copy link
Member

stof commented Dec 2, 2016

@fbourigault it would still have been public (it was necessary before) but it would have been an internal one.
And I would argue that a property not defined in the source code should not be considered part of the public API of Symfony.

@greg0ire
Copy link
Contributor

greg0ire commented Dec 2, 2016

I agree that we can't really expect an undeclared property to be part of the BC promise. Relying on it in the first place was a mistake. We must fix this on the Sonata side.

@fabpot
Copy link
Member

fabpot commented Dec 2, 2016

Does it mean we can close this one?

@greg0ire
Copy link
Contributor

greg0ire commented Dec 2, 2016

I think so.

@fbourigault
Copy link
Contributor Author

fbourigault commented Dec 2, 2016

Closing because this is not considered as a covered by BC break promise.

@fbourigault fbourigault closed this Dec 2, 2016
@fbourigault fbourigault deleted the fix-twig-bridge-bc-break branch December 2, 2016 12:35
@stof
Copy link
Member

stof commented Dec 2, 2016

@fbourigault it is not that we don't consider it as a BC break (it is one indeed). But we consider that it is not covered by our BC promise, as being part of an internal implementation

@greg0ire
Copy link
Contributor

greg0ire commented Dec 2, 2016

@fbourigault : I second that, everything is a BC-break ;)

bcbreak

@fbourigault
Copy link
Contributor Author

@stof @greg0ire I just used the wrong words in my closing comment!

@fbourigault
Copy link
Contributor Author

@nicolas-grekas opened a PR using magic methods: #20769

fabpot added a commit that referenced this pull request Dec 7, 2016
…::$renderer (nicolas-grekas)

This PR was merged into the 3.2 branch.

Discussion
----------

[Bridge\Twig] Trigger deprecation when using FormExtension::$renderer

| Q             | A
| ------------- | ---
| Branch?       | 3.2
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | yes (instead of a BC break)
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

As spotted in #20710 and sonata-project/SonataAdminBundle#4216.
Note that this simple implementation is fine because neither the class nor its parent have any private/protected properties.

Commits
-------

6f1c59c [Bridge\Twig] Trigger deprecation when using FormExtension::$renderer
@fabpot
Copy link
Member

fabpot commented Dec 7, 2016

Looks like we have reenabled the spacebar heating :)

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.

5 participants