Define polyfilled T_* constants from Tokenizer as int

[fredden]

Description

The value of these constants are not stable, and therefore already cannot be relied upon. This is because the specific values that PHP assigns can change with different versions of PHP. PHPCS does not use the values of these constants (other than to look up their name using the Tokens::tokenName() method).

There are other tools which also poly-fill these constants. Some of those tools also perform validation on the value for these constants. In order to play nicely with the arbitrary validation that other tools perform on these constants, we are switching from string values to integer values.

The PHP manual suggests "using big numbers like 10000" for poly-filled T_* constants. We have arbitrarily chosen to start our numbering scheme from 135_000.

All PHPCS 'native' tokens currently have reliable values. In line with PHP T_* constants, the values of these tokens should never be relied upon. In a future version of PHPCS, the values for these tokens will switch from strings to integers.

Existing tests already cover the use of these constants and do not require adjustment for the code being changed here.

Suggested changelog entry

• Change: poly-filled PHP T_* constants now have integer values. This makes no difference to PHPCS, but is done to increase compatibility with other tools which also poly-fill (and validate the values of) these same T_* tokens.
• Deprecate: the value of PHPCS native T_* constants should no longer be regarded as stable. In a future version their values will change from strings to integers. The Tokens::tokenName() method will continue to work when this change is made.

Related issues/external references

Fixes #1286

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
  • This change is only breaking for integrators, not for external standards or end-users.
• Documentation improvement

PR checklist

• I have checked there is no other PR open for the same change.
• I have read the Contribution Guidelines.
• I grant the project the right to include and distribute the code under the BSD-3-Clause license (and I have the right to grant these rights).
• I have added tests to cover my changes.
• I have verified that the code complies with the projects coding standards.
• [Required for new sniffs] I have added XML documentation for the sniff.
• I have opened a sister-PR in the documentation repository to update the Wiki.

[fredden]

@jrfnl the 'validate' step for "Find use of Tokens properties" check is failing on this code. Would you like me to rewrite the check or the code to avoid this?

[jrfnl]

@jrfnl the 'validate' step for "Find use of Tokens properties" check is failing on this code. Would you like me to rewrite the check or the code to avoid this?

What gets flagged is this:

src\Util\Tokens.php:135:Tokens::$polyfillMappingTable = $polyfillMappingTable;

I think updating the check to exclude this particular use would be most appropriate, though I'm not sure how straight-forward that would be.

[fredden]

I have worked out a way to use a static method after all. This means we don't need to change the CI/CD check for external use of deprecated properties.