Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
fabpot merged 1 commit intosymfony:3.2fromnicolas-grekas:fix-bc
Dec 7, 2016

Conversation

@nicolas-grekas
Copy link
Member

QA
Branch?3.2
Bug fix?yes
New feature?no
BC breaks?no
Deprecations?yes (instead of a BC break)
Tests pass?yes
Fixed tickets-
LicenseMIT
Doc PR-

As spotted in#20710 andsonata-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

Wow thanks for putting that much effort into BC!

@Koc
Copy link
Contributor

Koc commentedDec 5, 2016

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

*/
publicfunction__get($name)
{
if ('renderer' ===$name) {
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
MemberAuthor

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

@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'?

Koc reacted with thumbs up emoji

@greg0ire
Copy link
Contributor

greg0ire commentedDec 5, 2016
edited
Loading

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
MemberAuthor

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

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

nicolas-grekas commentedDec 6, 2016 via email
edited
Loading

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.
So be it. Throwing would prevent removing the magic methods to preserve thebehavior in 4.0, which is a no go to me.

@fbourigault
Copy link
Contributor

fbourigault commentedDec 6, 2016
edited
Loading

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

@nicolas-grekasnicolas-grekas added this to the3.2 milestoneDec 6, 2016
@nicolas-grekasnicolas-grekasforce-pushed thefix-bc branch 2 times, most recently fromf3d766e to295e4c1CompareDecember 6, 2016 15:25
@nicolas-grekas
Copy link
MemberAuthor

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

fbourigault and Koc reacted with thumbs up emoji

publicfunctioninitRuntime(\Twig_Environment$environment)
{
if (null !==$this->renderer) {
if ($this->rendererinstanceof 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
MemberAuthor

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 changesDec 6, 2016
* @internal
*/
publicfunction__set($name,$value)
{
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

* @internal
*/
publicfunction__get($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
MemberAuthor

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)

* @internal
*/
publicfunction__unset($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

"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
MemberAuthor

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

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 receivenull 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
MemberAuthor

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

@xabbuh
Copy link
Member

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

@fabpot
Copy link
Member

Thank you@nicolas-grekas.

@fabpotfabpot merged commit6f1c59c intosymfony:3.2Dec 7, 2016
fabpot added a commit that referenced this pull requestDec 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 andsonata-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-grekasnicolas-grekas deleted the fix-bc branchDecember 7, 2016 13:03
@fabpotfabpot mentioned this pull requestDec 13, 2016
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@stofstofstof left review comments

+2 more reviewers

@KocKocKoc left review comments

@SimperfitSimperfitSimperfit approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

3.2

Development

Successfully merging this pull request may close these issues.

10 participants

@nicolas-grekas@greg0ire@Koc@fbourigault@xabbuh@fabpot@stof@Simperfit@javiereguiluz@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp