[RFC] Readonly property hooks

Hey Larry,

Couple points from a first read and from trying to run the examples.

a) From the "ProductFromDB" i get:

Fatal error: Uncaught TypeError: LazyProduct::$category::get(): Return
value must be of type Category, none returned in ...

I assume you're missing a return statement here? Or is there something I'm
missing?

b) Minor wording gripe in the proposal section

On the other hand, there is no shortage of dumb things that people can do
with PHP already.

While I don't disagree that PHP gives people a lot of freedom in how they
want to write their code, I find it a bit crude for an RFC to phrase it
like that. And the __get comparison is strong enough to stand on its own.

c)

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

I might be misunderstanding the sentence here, but on-demand/Lazy
initialization of properties on readonly classes is already possible in
classic getter/setter classes.

Do you mean you want to have parity to this behavior when using hooks? I'm
all for it, I just feel the sentence says this enables something that
wasn't possible before but if you mean this in scope property access it
makes sense to me.

d) PositivePoint

Example doesn't compile against 8.4, master, or
against NickSdot:readonly-hooks

Can you make this a script that runs and shows expected output so that
readers don't have to assume this is supposed to do or run it?

e) Backward Incompatible Changes

Section is not filled in yet

f) Date: 2024-07-10

Is this correct? I know you created the page back then, but was there a
discussion already that I wasn't able to find?

Kind Regards,
Volker

On Sun, Jun 8, 2025 at 6:18 AM Larry Garfield larry@garfieldtech.com
wrote:

As Nick has graciously provided an implementation, we would like to open
discussion on this very small RFC to allow readonly on backed properties
even if they have a hook defined.

https://wiki.php.net/rfc/readonly_hooks

--
Larry Garfield
larry@garfieldtech.com

--
Volker Dusch
Head of Engineering
Tideways GmbH
Königswinterer Str. 116
53227 Bonn
https://tideways.io/imprint

Sitz der Gesellschaft: Bonn
Geschäftsführer: Benjamin Außenhofer (geb. Eberlei)
Registergericht: Amtsgericht Bonn, HRB 22127

Le 8 juin 2025 à 06:16, Larry Garfield larry@garfieldtech.com a écrit :

As Nick has graciously provided an implementation, we would like to open discussion on this very small RFC to allow readonly on backed properties even if they have a hook defined.

https://wiki.php.net/rfc/readonly_hooks

--
Larry Garfield
larry@garfieldtech.com

Hi Larry, Nick,

Last summer, the question of allowing hooks on readonly has been raised as part of the RFC «Property hooks improvements», and at that time I have raised an objection on allowing the get hook on readonly properties and I have suggested for a better design for the main issue it was supposed to solve, see https://externals.io/message/124149#124187 and the following messages. (The RFC itself was trimmed down to the non-controversial part.) I’ll repeat here both my objection and my proposal for better design, but more strongly, with the hope that the message will be received.

The purpose of readonly properties is (citing the original RFC, https://wiki.php.net/rfc/readonly_properties_v2#rationale) to provide strong immutable guarantee, i.e.:

class Test {
    public readonly string $prop;
 
    public function method(Closure $fn) {
        $prop = $this->prop;
        $fn(); // Any code may run here.
        $prop2 = $this->prop;
        assert($prop === $prop2); // Always holds.
    }
}

By allowing a get hook on readonly property, you are effectively nullifying this invariant. Invariants must be enforced be the engines (whenever possible; there is an inevitable loophole until the property is initialised), and not left to the discretion of the user. If a get hook on readonly property is allowed, a random user will use its creativity in order to circumvent the intended invariant (recall: immutability). I say “creativity”, not “dumbness”, because you cannot mechanically tell the two apart:

class doc {
    public readonly int page {
        get => $this->page + $this->offset;
    }
    private int $offset = 0;
    public function __construct(int $page) {
        $this->page = $page;
    }
    public function foo() {
        // $this->offset may be adjusted here
    }
}

I know that some people won’t see a problem with that code (see the cited thread above), and this is a strong reason not to allow that: you cannot trust the user to enforce invariants that they don’t understand or are not interested in.

(The objection above is for the get hook; there is no such issue with the set` hook.)

Now, here is the suggestion for a better alternative design, that (1) don’t allow to break the invariant of immutability, (2) solve the issue of lazy initialisation (which is, I guess, the main purpose of the get hook on readonly), and (3) also works with nullable properties:

Add an additional hook to backed properties, named init. When attempting to read the value of the backing store, if it is uninitialised, then the init hook is triggered, which is supposed to initialise it.

—Claude