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

[Debug] Support@final on methods#21465

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

Closed
GuilhemN wants to merge2 commits intosymfony:masterfromGuilhemN:DEBUGMETHODS

Conversation

@GuilhemN
Copy link
Contributor

QA
Branch?master
Bug fix?no
New feature?yes
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed tickets#21461 (comment)
LicenseMIT
Doc PR

This adds support for@final on methods:

class Foo {/**     * @final since version 2.0.     */publicfunctionbar()    {    }}

ping@nicolas-grekas

chalasr and ogizanagi reacted with thumbs up emoji
if ($parent) {
foreach ($refl->getMethods(\ReflectionMethod::IS_PUBLIC | \ReflectionMethod::IS_PROTECTED)as$method) {
try {
$prototype =$method->getPrototype();

Choose a reason for hiding this comment

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

Why isgetPrototype needed? (I'm not very familiar with it :) )

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

I discovered it today, it is fetching the parent method, which is what we need, we could do that manually but we would have to support several edge cases (for instance a method of the parent of the parent extended).

ogizanagi reacted with thumbs up emoji
Copy link
Contributor

Choose a reason for hiding this comment

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

@GuilhemN Very cool find. I've needed something similar in the past.

Copy link
Member

@nicolas-grekasnicolas-grekasJan 31, 2017
edited
Loading

Choose a reason for hiding this comment

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

Nice finding.
Then I'm wondering if we need it at all :)
Parent classes are always loaded before their children. This means each class should only look at methods that have$method->class === $class (let's use properties as much as possible, performance is critical here).
By populating theself::$finalMethods props, then children should have everything to decide quickly.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

@nicolas-grekas we would have to support the edge case I described above and maybe others i didn't think about, we would also have to parse every method doc blocks which is bad for perfs, imo it is better this way.

This means each class should only look at methods that have $method->class === $class

It looks like I forgot this check...

Copy link
Member

@nicolas-grekasnicolas-grekasJan 31, 2017
edited
Loading

Choose a reason for hiding this comment

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

parsing the docblock (doing an strpos preflight really) should be faster than trying getPrototype, then fall in the catch block, which involves instanciating a ReflectionException behind the scene - especially since this situation is going to happen quite often (since many methods don't have a "protototype")

Copy link
ContributorAuthor

@GuilhemNGuilhemNJan 31, 2017
edited
Loading

Choose a reason for hiding this comment

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

I tried it and the code is clearer too so 👍


if ($parent &&isset(self::$finalMethods[$parent][$method->name])) {
// Fetch the real class declaring the parent method
$prototype =$method->getPrototype();
Copy link
Member

@nicolas-grekasnicolas-grekasJan 31, 2017
edited
Loading

Choose a reason for hiding this comment

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

I guess you don't need this call if you compute the message when populatingself::$finalMethods[$name][$method->name]?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Good point 👍

}

$doc =$method->getDocComment();
// No @final annotation

Choose a reason for hiding this comment

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

the code says it :)

GuilhemN reacted with thumbs up emoji
self::$finalMethods[$name] =$parent &&isset(self::$finalMethods[$parent]) ?self::$finalMethods[$parent] :array();

foreach ($refl->getMethods(\ReflectionMethod::IS_PUBLIC | \ReflectionMethod::IS_PROTECTED)as$method) {
// It's not the declaring class

Choose a reason for hiding this comment

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

ueless to me :)

GuilhemN reacted with thumbs up emoji
@nicolas-grekasnicolas-grekas changed the titleSupport @final on methods[Debug] Support@final on methodsJan 31, 2017

$xError =array(
'type' =>E_USER_DEPRECATED,
'message' =>'The Symfony\Component\Debug\Tests\Fixtures\FinalMethod::finalMethod() method is considered final since version 3.3. It may change without further notice as of its next major version. You should not extend it from Symfony\Component\Debug\Tests\Fixtures\ExtendedFinalMethod.',
Copy link
Member

@nicolas-grekasnicolas-grekasJan 31, 2017
edited
Loading

Choose a reason for hiding this comment

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

would it be possible to turn this into an@expectedDeprecation annotation?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Sure, I just followed the rest of the file, I guess it was done to not add thelegacy group.

Choose a reason for hiding this comment

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

indeed!

}

// Not an interface nor a trait
if (class_exists($name,false)) {

Choose a reason for hiding this comment

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

this should also apply to@final on the class above, isn't it?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Yes but I think we should wait for this to be merged before doing it, to avoid conflicts.

Choose a reason for hiding this comment

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

I don't see why?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

In fact it's not a big deal, I can just rebase this PR if we do it in another PR.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

done

Copy link
Member

@nicolas-grekasnicolas-grekas left a comment

Choose a reason for hiding this comment

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

👍

@fabpot
Copy link
Member

Thank you@GuilhemN.

GuilhemN and sstok reacted with hooray emoji

@fabpotfabpot closed thisFeb 12, 2017
fabpot added a commit that referenced this pull requestFeb 12, 2017
This PR was squashed before being merged into the 3.3-dev branch (closes#21465).Discussion----------[Debug] Support `@final` on methods| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#21461 (comment)| License       | MIT| Doc PR        |This adds support for `@final` on methods:```phpclass Foo {    /**     *@Final since version 2.0.     */    public function bar()    {    }}```ping@nicolas-grekasCommits-------1b0a6b6 [Debug] Support  on methods
@GuilhemNGuilhemN deleted the DEBUGMETHODS branchFebruary 13, 2017 15:35
nicolas-grekas added a commit that referenced this pull requestMar 27, 2017
This PR was merged into the 3.3-dev branch.Discussion----------[HttpFoundation] Fix bad merge| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets | -| License       | MIT| Doc PR        | -Bad merge, code had been removed in#21465Commits-------af1eed9 [HttpFoundation] Fix bad merge
@fabpotfabpot mentioned this pull requestMay 1, 2017
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@nicolas-grekasnicolas-grekasnicolas-grekas approved these changes

+1 more reviewer

@robfrawleyrobfrawleyrobfrawley left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

3.3

Development

Successfully merging this pull request may close these issues.

5 participants

@GuilhemN@fabpot@nicolas-grekas@robfrawley@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp