Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127632
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 09 Jun 2025 17:04:39 +0200
To: Nick <php@nicksdot.dev>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Allow hooks in `readonly` promoted properties
In-Reply-To: <E51C9FF4-0955-4D9A-8B0A-B2B9F9CD2B36@nicksdot.dev>
References: <B0250A18-3C43-4DFD-9D99-3391C23D9D65@nicksdot.dev>
 <f4d0567f-c364-433b-b5b7-60fae49f9046@app.fastmail.com>
 <28F14D0F-8483-418D-85D1-660564A4EAE2@nicksdot.dev>
 <bfec2063-5304-48c1-bc19-203eb62c1237@app.fastmail.com>
 <26AA81AF-1610-494D-A811-10F7B282CBD4@nicksdot.dev>
 <1c0df916e4cfbc746b5dddf935d165a9@bastelstu.be>
 <E51C9FF4-0955-4D9A-8B0A-B2B9F9CD2B36@nicksdot.dev>
Message-ID: <eb9f1bd5d1b58fd5a2f3f7bc623e9033@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2025-06-05 08:04, schrieb Nick:
>> Semantically once you involved inheritance it isn't that easy. It is 
>> allowed to override an “unhooked” property with a hooked property and 
>> in the “Readonly Amendments” RFC we already decided that inheriting 
>> from a `readonly` class by a non-`readonly` class should not be valid.
> 
> I added tests for this. The behaviour you expect seems confirmed.

I think you might have misunderstood me there. I was not specifically 
discussing the inheritance of readonly and non-readonly classes, but the 
user’s expectations for the semantics of readonly classes. This 
paragraph was intended as an introduction for the following paragraphs.

To be clear: The tests do not confirm my expected behavior, since I 
expect a `readonly` property to never change after successfully reading 
it. But that's something for the official RFC discussion.

>> 
>> So if you would be allowed to override a readonly unhooked property 
>> with a hooked property that has a `get` hook that is not a pure 
>> function, you would make the property effectively mutable, which is 
>> something that users of the class can't expect. It violates the 
>> history property of the Liskov substitution principle.
>> 
>> Making this legal might also inhibit engine optimization. Currently if 
>> you know that a property is readonly you can theoretically optimize:
>> 
>>    if ($object->foo !== null) {
>>        do_something($object->foo);
>>    }
>> 
>> into:
>> 
>>    if (($foo = $object->foo) !== null) {
>>        do_something($foo);
>>    }
>> 
>> to avoid reading `$object->foo` twice, which for example would need to 
>> check visibility twice.
> 
> Added 
> Zend/tests/property_hooks/readonly_property_backed_inheritance_3.phpt
> 
> Personally, I’d argue nothing unexpected happens here and everything is 
> fair game.
> If we overwrite parents from a child it will naturally result in a 
> changed get hook result.
> This, however, does not mean the actual class state has changed.

I'd argue that the user is not interested in the “actual class state”, 
but what they can observe from interacting with the class. I'll probably 
discuss this in more detail in the official RFC discussion thread.

Best regards
Tim Düsterhus