Skip to content

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

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
Dec 7, 2016

Conversation

nicolas-grekas
Copy link
Member

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.

@greg0ire
Copy link
Contributor

greg0ire commented Dec 5, 2016

Wow thanks for putting that much effort into BC!

@Koc
Copy link
Contributor

Koc commented Dec 5, 2016

I am afraid that this property is not initialized anymore but haven't tested yet.

public function __get($name)
{
if ('renderer' === $name) {
@trigger_error(sprintf('Using the "%s::$renderer" property is deprecated since version 3.2 as it will be made private in 4.0.', __CLASS__), E_USER_DEPRECATED);
Copy link
Contributor

Choose a reason for hiding this comment

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

Actually it will be removed in 4.0

Copy link
Member Author

Choose a reason for hiding this comment

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

updated

@greg0ire
Copy link
Contributor

greg0ire commented Dec 5, 2016

@Koc : yes it is I think

@fbourigault
Copy link
Contributor

Is it safer to throw an Exception when using magic methods with something else than '$renderer'?

@greg0ire
Copy link
Contributor

greg0ire commented Dec 5, 2016

Proof Travis job. Not sure it completely works though… maybe something more needs to be done (the initialization @Koc was talking about?)

Here is the output without your changes

@nicolas-grekas
Copy link
Member Author

Is it safer to throw an Exception when using magic methods with something else than '$renderer'?

this is unrelated and wouldn't match the behavior in 4.0

@xabbuh
Copy link
Member

xabbuh commented Dec 6, 2016

@nicolas-grekas But it allows us to add private or protected properties in the future without exposing them. Otherwise we would have to remember to update the magic getter and setter methods.

@nicolas-grekas
Copy link
Member Author

nicolas-grekas commented Dec 6, 2016 via email

@fbourigault
Copy link
Contributor

fbourigault commented Dec 6, 2016

@nicolas-grekas, you must also re-inject the renderer in the service definition as it was removed when this break was introduced.

@nicolas-grekas nicolas-grekas added this to the 3.2 milestone Dec 6, 2016
@nicolas-grekas nicolas-grekas force-pushed the fix-bc branch 2 times, most recently from f3d766e to 295e4c1 Compare December 6, 2016 15:25
@nicolas-grekas
Copy link
Member Author

The renderer is now reinjected, but in a lazy way. PR ready.

@@ -40,7 +46,7 @@ public function __construct(TwigRendererInterface $renderer = null)
*/
public function initRuntime(\Twig_Environment $environment)
{
if (null !== $this->renderer) {
if ($this->renderer instanceof TwigRendererInterface) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we initialize renderer here?

Copy link
Member Author

Choose a reason for hiding this comment

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

done (in a lazy way again)

stof
stof previously requested changes Dec 6, 2016
*/
public function __set($name, $value)
{
if ('renderer' === $name) {
Copy link
Member

Choose a reason for hiding this comment

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

we should throw an exception for any other name

*/
public function __get($name)
{
if ('renderer' === $name) {
Copy link
Member

Choose a reason for hiding this comment

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

we should throw an exception for any other name

Copy link
Member Author

Choose a reason for hiding this comment

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

no no no, see #20769 (comment)

*/
public function __unset($name)
{
if ('renderer' === $name) {
Copy link
Member

Choose a reason for hiding this comment

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

we should forbid any other name

@@ -17,7 +17,7 @@
],
"require": {
"php": ">=5.5.9",
"symfony/twig-bridge": "~3.2",
"symfony/twig-bridge": "~3.2,>=3.2.1",
Copy link
Member

Choose a reason for hiding this comment

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

use ^3.2.1, which is exactly what you did here with 2 constraints

Copy link
Member Author

Choose a reason for hiding this comment

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

updated

@xabbuh
Copy link
Member

xabbuh commented Dec 6, 2016

So be it. Throwing would prevent removing the magic methods to preserve the
behavior in 4.0, which is a no go to me.

@nicolas-grekas But the current implementation would suffer the same. You would receive null now, but you will get a PHP error with Symfony 4.0. Throwing an exception now would at least warn users to be aware that they do something wrong.

@nicolas-grekas
Copy link
Member Author

They will get exactly the same behavior as if the property did not exist: a PHP notice.
See https://3v4l.org/YBvLe

@xabbuh
Copy link
Member

xabbuh commented Dec 7, 2016

Oh indeed, I didn't say anything then. :)

@fabpot
Copy link
Member

fabpot commented Dec 7, 2016

Thank you @nicolas-grekas.

@fabpot fabpot merged commit 6f1c59c into symfony:3.2 Dec 7, 2016
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
@nicolas-grekas nicolas-grekas deleted the fix-bc branch December 7, 2016 13:03
@fabpot fabpot mentioned this pull request Dec 13, 2016
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.

10 participants