Table of Contents

PHP RFC: Readonly hooks

Introduction

Support for hooks on readonly properties was omitted from the original RFC, primarily to minimize complexity as there were questions around when it was safe to do. On further consideration, we believe that hooks on backed properties are sufficiently safe to support readonly, but not on virtual properties.

Proposal

We propose to allow both get and set hooks on readonly properties, if and only if it is a backed property.

Concerns to address

The main concern of allowing readonly hooks is that readonly, in theory, implies a property is immutable and idempotent. However, a get hook supports arbitrary code, so technically a developer could do something like: 

class Unusual
{
    public readonly int $value { get => $this->value * random_int(1, 100); }
}

However, the same strange behavior could be implemented using __get: 

class Test 
{
    public readonly int $test;
 
    public function __construct() 
    {
        unset($this->test);
    }
 
    public function __get($prop)
    {
        if ($prop === 'test') {
            return random_int(1, 100);
        }
    }
}
 
$t = new Test();
 
// These will print different numbers.
var_dump($t->test);
var_dump($t->test);

That means the guarantee that readonly is idempotent is already not enforceable today, and in fact never has been.

Uses

Despite the lack of a hard idempotency guarantee, there are valid uses for a readonly get hook, especially for ORMs and proxies. For example: 

readonly class Product
{
    public function __construct(
        public string $name,
        public float $price,
        public Category $category,
    ) {}
}
 
// Generated code.
readonly class LazyProduct extends Product
{
   private DbConnection $dbApi;
 
   private string $categoryId;
 
   public Category $category {
       get {
           return $this->category ??= $this->dbApi->loadCategory($this->categoryId);
       }
   }
}

That is, we feel, an entirely reasonable use of hooks, and would allow for lazy-load behavior per-property on readonly classes.

This is subtly different from the Lazy Proxy RFC, which operates on the whole object at once. We believe both use cases are valuable and should be supported.

A set hook, meanwhile, offers no issue for a backed readonly property. As long as it is backed we are able to determine if it is still uninitialized, and so a second set call would correctly fail as it should.

For example, one of the recommended uses of hooks is for property validation. Such validation would not in any way impede the readonly-ness of a backed property. 

readonly class PositivePoint 
{
    public function __construct(
        public int $x { set => $value > 0 ? $value : throw new \Exception(); },
        public int $y { set => $value > 0 ? $value : throw new \Exception(); },
    ) {}
}

The above is not legal in 8.4, but it seems entirely safe to do for 8.5.

On balance, we believe the advantages and use cases for hooked readonly properties outweigh the potential for developers to do wonky things. For that reason, we propose to allow both get and set hooks on backed readonly properties.

Backward Incompatible Changes

None. No previously-valid code will become invalid. While it will be possible for a readonly property to return different values on subsequent calls, that is already the case as demonstrated above. So no guarantees are softened by this RFC.

Proposed PHP Version(s)

PHP 8.5

RFC Impact

Proposed Voting Choices

Yes or no vote. 2/3 required to pass.

Approve backed readonly hooks?
Real name Yes No
Final result: 0 0
This poll has been closed.

Patches and Tests

Link to the PR: https://github.com/php/php-src/pull/18757

Implementation

References