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
