Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Mark class-constants as non-deprecated #50680

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

Conversation

heiglandreas
Copy link
Contributor

Q A
Branch? 6.2
Bug fix? yes
New feature? no
Deprecations? no
Tickets None
License MIT
Doc PR none

Static analysis tools like PHPStan treat the @deprecated flag as inherited. So when a class constant is marked as deprecated, then the same class constant in an extending class is also marked deprecated unless it gets explicitly marked as @non-deprecated.

Without this flag PHPStan currenlty will return the message

Fetching deprecated class constant LAST_USERNAME of class Symfony\Bundle\SecurityBundle\Security:                          
since Symfony 6.2, use \Symfony\Bundle\SecurityBundle\Security::LAST_USERNAME instead 

which is not really helpful as that is exactly what one did at that point.

By marking these class-constants as @non-deprecated PHPStan and other static analysis tools can recognize these class constants as being the rightly used ones.

For more information have a look at the discussion at phpstan/phpstan-deprecation-rules#100

Static analysis tools like PHPStan treat the `@deprecated` flag as inherited. So when a class constant is marked as deprecated, then the same class constant in an extending class is also marked deprecated unless it gets explicitly marked as `@non-deprecated`.

Without this flag PHPStan will return the message 

```
Fetching deprecated class constant LAST_USERNAME of class Symfony\Bundle\SecurityBundle\Security:                          
since Symfony 6.2, use \Symfony\Bundle\SecurityBundle\Security::LAST_USERNAME instead 
```
which is not really helpful as that is exactly what one did at that point.

By marking these class-constants as `@non-deprecated` PHPStan and other static analysis tools can recognize these class constants as being the rightly used ones.

For more information have a look at the discussion at phpstan/phpstan-deprecation-rules#100
@carsonbot
Copy link

Hey!

Thanks for your PR. You are targeting branch "6.4" but it seems your PR description refers to branch "6.2".
Could you update the PR description or change target branch? This helps core maintainers a lot.

Cheers!

Carsonbot

@carsonbot carsonbot added this to the 6.4 milestone Jun 16, 2023
@derrabus
Copy link
Member

Maybe we should actually deprecate them as well, given that the constants are duplicated on the SecurityRequestAttributes class and we somewhat create two sources of truth for the same thing.

I probably didn't fully understand the rationale behind #48554 though. 🙈 /cc @IonBazan @chalasr

@ro0NL
Copy link
Contributor

ro0NL commented Jun 16, 2023

@non-deprecated looks weird, is it a standard? IMHO redeclaring implicitly undeprecates it

also https://psalm.dev/r/f642da203a https://phpstan.org/r/89339c04-ac08-4f6a-b0ab-241f60670c3f

2 tools, 1 lang does not work :)

@wouterj
Copy link
Member

wouterj commented Jun 16, 2023

I'm -1 on adding these annotations to Symfony, as they violate our phpdoc standards. Given only one tool (with an extra ruleset) uses this annotation as far as I know, this better belongs in the PHPstan stubs (as also suggested by Ondrej).

But I'm +1 on deprecating these constants as well in favor of SecurityRequestAttributes. It does not make sense to have them in both places imho. Would love to hear @chalasr's opinion here, given the previous PR undeprecated these.

@nicolas-grekas
Copy link
Member

I'm closing as discussed, but I'm also looking forward to the PR that will deprecate these consts!

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.

6 participants