`AbstractVariableSniff`: how should promoted properties be handled?

[rodrigoprimo]

Promoted properties (introduced in PHP 8.0) are both a function parameter and an object property. This raises the question of how the AbstractVariableSniff class should handle them when finding T_VARIABLE tokens.

Current behavior

Consider the following code:

class MyClass {
    public function __construct(
        public string $promotedProperty = 'bar',
    ) {}
}

Currently, promoted properties are routed to processVariable() (not processMemberVar()). This happens because AbstractVariableSniff checks if a variable is inside a function's parameter list and treats it as "in a function", routing it to processVariable().

This means that sniffs extending AbstractVariableSniff will process promoted properties as function parameters, not as object properties.

Questions for discussion

How should sniffs extending AbstractVariableSniff handle promoted properties?

• As an object property (via processMemberVar())?
• As a function parameter (keeping current behavior via processVariable())?
• Both as an object property and as a function parameter?
• Something else (for example, introducing a new method specifically for promoted properties)?

It is important to consider that this will affect all standards that use sniffs extending AbstractVariableSniff for variable naming validation, including external standards.

Related discussions

There is a discussion about how the Squiz.NamingConventions.ValidVariableName sniff should handle promoted properties in #512, but I thought it made sense to start a broader conversation about how AbstractVariableSniff should handle it.

[jrfnl]

How should sniffs extending AbstractVariableSniff handle promoted properties?

PHP will validate promoted properties as both parameters as well as properties and apply whatever rules apply to either to them.

I think it makes sense for PHPCS to do the same, but as you rightfully pointed out, that will have a not insignificant impact on existing sniffs.

In practice, the actual desired behaviour will very much depend on the type of sniff (code style vs functional) and on the individual standard. For example. some standards may want promoted properties to comply with property naming conventions, some will want them to comply with parameter naming conventions and some may want them to comply with both.

All in all, I don't think there is one solution which will fit all use cases.

I kind of wonder whether the AbstractVariableSniff hasn't outlived its usefulness and whether sniffs using it shouldn't switch to using the utilities from PHPCSUtils to design the sniff based on the specific rules they want to apply instead.

@rodrigoprimo Is there a specific usecase/reason why you are asking about this abstract now ?

[rodrigoprimo]

@rodrigoprimo Is there a specific usecase/reason why you are asking about this abstract now ?

No particular reason for the timing. Back in early September, we briefly discussed how WordPress.NamingConventions.ValidVariableName should handle promoted properties, and you suggested I open issues in both repositories. It took me a while, but I finally got around to creating them yesterday.