PHP RFC: Asymmetric Visibility for Static Properties

• Version: 0.9
• Date: 2024-10-23
• Author: Ilija Tovilo (tovilo.ilija@gmail.com), Larry Garfield (larry@garfieldtech.com)
• Status: Draft
• First Published at: http://wiki.php.net/rfc/static-aviz

The Asymmetric Visibility RFC for PHP 8.4 deliberately omitted support for asymmetric visibility on static properties. That was due primarily to the expected implementation complexity, and relatively few use cases. However, further investigation found that it was easier to implement than anticipated, so this RFC seeks to add asymmetric visibility for static properties as well, for completeness.

All behavior described in the Asymmetric Visibility v2 RFC (linked above) for object properties will apply for static properties in the exact same way. See that RFC for complete details, as they are identical here.

class Example
{
    public private(set) static string $classTitle = 'Example class';
 
    // Implicitly public-read, just like object properties.
    protected(set) static int $counter = 0;
 
    public static function changeName(string $name): void
    {
        // From private scope, so this is allowed.
        self::$classTitle = $name;
    }
}
 
print Example::$classTitle; // Allowed.
 
Example::$classTitle = 'Nope'; // Disallowed.

Note that some aviz functionality relates to final properties specifically, such as private(set) being implicitly final. final static properties are already supported in PHP, so that poses no concern for this RFC.

Of note, readonly and property hooks are not affected by this RFC. Those remain available only on object properties. They have their own implementation complexities and use case considerations, and if there is interest would be a subject for another time.

None.

PHP 8.5

The behavior of asymmetric visibility on object properties is unaffected by this RFC.

The behavior of existing static properties is unaffected by this RFC.

2/3 yes or no vote.

https://github.com/php/php-src/pull/16486

After the project is implemented, this section should contain

1. the version(s) it was merged into
2. a link to the git commit(s)
3. a link to the PHP manual entry for the feature
4. a link to the language specification section (if any)

Links to external references, discussions or RFCs

Keep this updated with features that were discussed on the mail lists.