8000 Extract method refactoring for ResourceCheckerConfigCache by mpdude · Pull Request #22589 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

Extract method refactoring for ResourceCheckerConfigCache #22589

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 2 commits into from
Closed

Extract method refactoring for ResourceCheckerConfigCache #22589

wants to merge 2 commits into from

Conversation

mpdude
Copy link
Contributor
@mpdude mpdude commented Apr 30, 2017
Q A
Branch? master
Bug fix? no
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets
License MIT
Doc PR

Improves code readability.

throw $e;
}
if (false === $meta) {
return false;
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this should become null instead of false, the way the method is used, it looks like a nullable return type.

Copy link
Member

Choose a reason for hiding this comment

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

the return type is mixed, so nullable or not doesn't matter really.
Still, this "if" should be just removed, the return $meta; below is enough here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch! I just extracted the method without additional scrutinity and indeed these lines are no longer needed.

@nicolas-grekas nicolas-grekas added this to the 3.3 milestone May 2, 2017
@dunglas
Copy link
Member
dunglas commented May 9, 2017

This class exist since 2.8. Shouldn't this refactoring (if it's worth) be done in this branch?

@chalasr
Copy link
Member
chalasr commented May 10, 2017

I think refactoring should be done on master. Maintenance branches should be updated for bug fixes only, avoiding behavior changes and silly BC breaks on patch releases (potentially breaking apps expecting to be safe by locking on a LTS, and that for no strong reason).

@mpdude
Copy link
Contributor Author
mpdude commented May 11, 2017

@chalasr ... which is exactly how this is handled.

@chalasr
Copy link
Member
chalasr commented May 11, 2017

@mpdude sure, just to give one more point of view :) this looks good to me.

@dunglas
Copy link
Member
dunglas commented May 11, 2017

@chalasr the problem of refactoring in the master branch is that it increases the number of merge conflicts when merging other PRs from lower branches to higher.

@chalasr
Copy link
Member
chalasr commented May 11, 2017
8000

Sure. Question is ... do we prefer merge conflicts potentially leading to bad merges on our dev branch (internal and, most of the times, quickly fixed) or potential breakages on production (userland, stable stuff suddenly broken with generally 1month for being fixed)

@fabpot fabpot modified the milestones: 3.4, 3.3 May 11, 2017
@ro0NL
Copy link
Contributor
ro0NL commented May 16, 2017

It's not refactoring really.. just moving code around :) i would do this on 2.8 to avoid the merge conflicts.

But is it worth it? 🤔 we only change a single occurrence; i.e. what are you solving?

@mpdude
Copy link
Contributor Author
mpdude commented May 16, 2017

Improving clarity, always worth it.

@nicolas-grekas nicolas-grekas changed the base branch from master to 3.4 May 23, 2017 16:59
@mpdude
Copy link
Contributor Author
mpdude commented Jun 3, 2017

@fabot What do you think – should such refactorings go into the oldest branch to avoid merge conflicts later on, or are changes on old branches strictly bugfix-only?

@fabpot
Copy link
Member
fabpot commented Jun 5, 2017

Doing this in 3.4 looks good to me.

@nicolas-grekas
Copy link
Member

Thank you @mpdude.

nicolas-grekas added a commit that referenced this pull request Sep 26, 2017
…e (mpdude)

This PR was squashed before being merged into the 3.4 branch (closes #22589).

Discussion
----------

Extract method refactoring for ResourceCheckerConfigCache

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets |
| License       | MIT
| Doc PR        |

Improves code readability.

Commits
-------

685c353 Extract method refactoring for ResourceCheckerConfigCache
@mpdude mpdude deleted the refactor-resource-checker-config-cache branch September 26, 2017 18:36
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
0