On Thu, Jul 10, 2025, at 5:43 AM, Tim Düsterhus wrote: > Hi > > Am 2025-07-08 17:32, schrieb Nicolas Grekas: >> I also read Tim's argument that new features could be stricter. If one >> wants to be stricter and forbid extra behaviors that could be added by >> either the proposed hooks or __get, then the answer is : make the class >> final. This is the only real way to enforce readonly-ness in PHP. > > Making the class final still would not allow to optimize based on the > fact that the identity of a value stored in a readonly property will not > change after successfully reading from the property once. Whether or not > a property hooked must be considered an implementation detail, since a > main point of the property hooks RFC was that hooks can be added and > removed without breaking compatibility for the user of the API. > >> engine-assisted strictness in this case. You cannot write such code in >> a >> non-readonly way by mistake, so it has to be by intent. > > That is saying "it's impossible to introduce bugs". > >> PS: as I keep repeating, readonly doesn't immutable at all. I know this >> is >> written as such in the original RFC, but the concrete definition and >> implementation of readonly isn't: you can set mutable objects to >> readonly >> properties, and that means even readonly classes/properties are >> mutable, in >> the generic case. > > `readonly` guarantees the immutability of identity. While you can > certainly mutate mutable objects, the identity of the stored object > doesn't change. > > Best regards > Tim Düsterhus
Nick previously suggested having the get-hook's first return value cached; it would still be subsequently called, so any side effects would still happen (though I don't know why you'd want side effects), but only the first returned value would ever get returned. Would anyone find that acceptable? (In the typical case, it would be the same as the current $this->foo ??= compute() pattern, just with an extra cache entry.) --Larry Garfield
