Problem/Motivation
State what you believe is wrong or missing from the current standards.
There are places in Drupal where we have string values referring to class names.
Often these values are initialized with regular string literals. This makes it hard for an IDE (I only tried with PhpStorm, no idea about others) to
- list these string literals in "find usages" for a class.
- provide auto-completion when writing this code.
- warn you about non-existing or misspelled classes.
- include these string literals in refactor/rename.
PHP provides a syntax where all this is supported: "::class".
I propose that this becomes the recommended way of referring to class names as strings.
Example
In Drupal\Core\Cache\ApcuBackendFactory::__construct():
Current code:
$this->backendClass = 'Drupal\Core\Cache\ApcuBackend';
could be replaced with
$this->backendClass = \Drupal\Core\Cache\ApcuBackend::class;
or better
[..]
use Drupal\Core\Cache\ApcuBackend;
[..]
$this->backendClass = ApcuBackend::class;
Side note
The same problem exists with procedural callbacks, or string method names. Unfortunately there is no foo::function syntax in PHP. I personally always put a @see comment on top of string literals referring to functions or callbacks, to facilitate "find usages". But this should be dealt with in a separate issue.
For code that relies on php5.5+ (so drupal 8 or contrib code that needs dependencies that are 5.5+), when referencing a class,
the ::class syntax MUST be used.
All references to classes that are spposed to be a string, should use this style.
Benefits
If we adopted this change, the Drupal Project would benefit by ...
Three supporters required
-
https://www.drupal.org/u/ →
{userid} (yyyy-mm-dd they added support)
-
https://www.drupal.org/u/ →
{userid} (yyyy-mm-dd they added support)
-
https://www.drupal.org/u/ →
{userid} (yyyy-mm-dd they added support)
Proposed changes
Provide all proposed changes to the Drupal
Coding standards →
. Give a link to each section that will be changed, and show the current text and proposed text as in the following layout:
1. {link to the documentation heading that is to change}
Add current text in blockquotes
Add proposed text in blockquotes
2. Repeat the above for each page or sub-page that needs to be changed.
Remaining tasks
- Add supporters
- Create a Change Record
- Review by the Coding Standards Committee
- Coding Standards Committee takes action as required
- Discussed by the Core Committer Committee, if it impacts Drupal Core
- Final review by Coding Standards Committee
- Documentation updates
- Edit all pages
- Publish change record
- Remove 'Needs documentation edits' tag
- If applicable, create follow-up issues for PHPCS rules/sniffs changes
For a full explanation of these steps see the
Coding Standards project page →
