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

Skip to content

[Validator] Used "::class" name resolution instead of "__NAMESPACE__" constant #19692

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
Closed

[Validator] Used "::class" name resolution instead of "__NAMESPACE__" constant #19692

wants to merge 1 commit into from

Conversation

SoboLAN
Copy link

@SoboLAN SoboLAN commented Aug 21, 2016

Q A
Branch? master and 3.1
Bug fix? no
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets N/A
License MIT
Doc PR N/A

The obscurity of building full Constraint class names by concatenating strings is removed. This could make it easier for some IDEs or other static analysis tools to identify usages of that specific class.

More details about "::class": http://php.net/manual/en/language.oop5.basic.php#language.oop5.basic.class.class

PS: It could be a good idea to apply this throughout the code, not just in Validator Component.

…PACE__" magic constant

The obscurity of building full Constraint class names by concatenating strings is therefore removed. This could make it easier for some IDEs or other static analysis tools to identify usages of that specific class.

More details about "::class": http://php.net/manual/en/language.oop5.basic.php#language.oop5.basic.class.class
@Koc
Copy link
Contributor

Koc commented Aug 21, 2016

duplicates #17420

@SoboLAN
Copy link
Author

SoboLAN commented Aug 21, 2016

@Koc Hmmm, did not see that PR.

I'm surprised to see that it was closed instead of merged. The ::class language construct is a very useful and much cleaner alternative.

@jameshalsall
Copy link
Contributor

@SoboLAN because it would cause problems merging upstream changes for 2.7 and 2.8

@ro0NL
Copy link
Contributor

ro0NL commented Aug 21, 2016

👍 clean syntax / ide support.

Upstream merge conflicts are overrated. This hardly ever changes.

@nicolas-grekas
Copy link
Member

We all agree that this syntax is better, and that's why we use it since 3.0 for new features. But for 2.7/2.8, the regular merges of 2.8 into 3.x would create merge conflicts during the whole lifetime of the 2.8 version, which means many years since it's an LTS. That's why we already refused this and we must stick to this policy.

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