The PHP Asymmetric Visibility RFC introduces a significant enhancement to PHP’s property visibility control.

Traditionally, PHP properties have symmetric visibility, meaning the same visibility rules apply to both read and write operations.

This RFC proposes a change to allow asymmetric visibility, where properties can have different visibility modifiers for read and write operations.

This new feature aims to provide developers with more granular control over class properties, enhancing encapsulation and API design flexibility.

Proposal Overview

Asymmetric visibility allows developers to define separate visibility rules for reading and writing a property. For instance, a property can be public for read operations but private or protected for write operations.

Syntax

The proposed syntax borrows from Swift’s access control and looks as follows:

class Foo {
    public private(set) string $bar = 'baz';
}

$foo = new Foo();
echo $foo->bar; // Outputs: baz
$foo->bar = 'beep'; // Visibility error

In this example, the property $bar can be read publicly but can only be modified privately within the class.

Key Features

1. Constructor Property Promotion: Asymmetric visibility can be used in constructor property promotion, which simplifies the initialization of objects.

   class Foo {
       public function __construct(public private(set) string $bar) {}
   }
   
   

2. Abbreviated Form: To ease the common usage pattern, if a set visibility is specified, the public get visibility may be omitted.

   private(set) string $foo;
   protected(set) string $foo;
   
   

3. Inheritance Rules: Asymmetric visibility respects PHP’s current inheritance rules, ensuring compatibility and avoiding breaking changes. However, properties declared with private(set) are implicitly final to prevent them from being redeclared with a wider set visibility in child classes.

Compatibility and Interactions

Property Hooks Interaction

The asymmetry in visibility will not interact with property hooks introduced in the Property Hooks RFC.

These features operate independently, and a property’s asymmetric visibility won’t affect the behavior injected by hooks. The only exception is for virtual properties that lack a set operation, which will generate a compile error if visibility for the set operation is specified.

Interface Properties

Interfaces and abstract classes can declare property requirements with get and set operations separately. Asymmetric visibility can effectively satisfy these requirements, provided the operations align with the specified visibility in the interface.

Practical Applications

1. Encapsulation Enhancement: Developers can expose internal states safely. For instance, a readonly implementation can now be replaced with a more flexible protected(set) or private(set).

2. Struct-like Classes: It simplifies the creation of classes that behave like data structs but require controlled mutability.

   class Book {
       public function __construct(private(set) string $title, private(set) Author $author, private(set) int $pubYear) {}
   }
   
   

3. Controlled References: Obtaining references to properties obeys the set visibility, thus preventing unauthorized modifications while allowing read access in the desired scope.

The RFC lays the groundwork for potential future enhancements, such as additional visibility controls for package-level visibility or operations like reference obtaining (protected(&get)).

These expansions would integrate seamlessly with the proposed asymmetric visibility syntax.

The PHP Asymmetric Visibility RFC represents a thoughtful extension to the existing visibility controls, addressing several limitations of symmetric property visibility.

By adopting this RFC, PHP developers gain finer control over property access, enhancing both encapsulation and flexibility in API design.

This proposal is a testament to PHP’s evolving capability to offer more robust, developer-friendly features without compromising backward compatibility.

← Go back to the blog