Re: [RFC] Readonly property hooks

On Fri, Jul 11, 2025, at 13:40, Nick wrote: > >> On 11. Jul 2025, at 01:43, Rob Landers <rob@bottled.codes> wrote: >> >> On Thu, Jul 10, 2025, at 17:34, Larry Garfield wrote: >>> 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 >>> >> >> I think that only covers one use-case for getters on readonly classes.. Take this example >> for discussion: >> >> readonly class User { >> public int $elapsedTimeSinceCreation { get => time() - $this->createdAt; } >> private int $cachedResult; >> public int $totalBalance { get => $this->cachedResult ??= 5+10; } >> public int $accessLevel { get => getCurrentAccessLevel(); } >> public function __construct(public int $createdAt) {} >> } >> >> $user = new User(time() - 5); >> var_dump($user->elapsedTimeSinceCreation); // 5 >> var_dump($user->totalBalance); // 15 >> var_dump($user->accessLevel); // 42 >> >> In this example, we have three of the most common ones: >> 1. Computed Properties (elapsedTimeSinceCreation): these are properties of the object that >> are relevant to the object in question, but are not static. In this case, you are not writing to the >> object. It is still "readonly". >> 2. Memoization (expensiveCalculation): only calculate the property once and only once. >> This is a performance optimization. It is still "readonly". >> 3. External State (accessLevel): properties of the object that rely on some external >> state, which due to architecture or other convienence may not make sense as part of object >> construction. It is still "readonly". >> You can mix-and-match these to provide your own level of immutability, but memoization is >> certainly not the only one. >> >> You could make the argument that these should be functions, but I'd posit that these >> are properties of the user object. In other words, a function to get these values would probably be >> named getElapsedTimeSinceCreation(), >> getTotalBalance, or getAccessLevel >> -- we'd be writing getters anyway. >> >> — Rob > Hey Rob, > > We ended up where we are now because more people than not voiced that they would expect a > readonly property value to never change after > get was first called. > As you can see in my earlier mails I also was of a different opinion. I asked "what if a > user wants exactly that”? > You brought good examples for when “that" could be the case. > > It is correct, with the current alternative implementations your examples would be cached. > A later call to the property would *not* use the updated time or a potentially updated external > state. > > After thinking a lot about it over the last days I think that makes sense. > > To stick to your usage of time(), I think the following is a > good example: > > ```php > readonly class JobHelper > { > public function __construct( > public readonly string $uniqueRunnerKey { > get => 'runner/' . date("Ymd_H-i-s", time()) . '_' > . (string) random_int(1, 100) . '/'. $this->uniqueRunnerKey; > } > ) {} > } > > $helper = new JobHelper('report.txt’); > $key1 = $helper->uniqueRunnerKey; > sleep(2); > $key2 = $helper->uniqueRunnerKey; > var_dump($key1 === $key2); // true > ``` > > It has two dynamic path elements, to achieve some kind of randomness. As a user you still can > expect $key1 === $key2 to hold when using readonly. > > Claude's argument is strong, because we also cannot write twice to a > readonly property. > So it’s fair to say reading should also be predictable, and return the exact same value on > consecutive calls. > > If users don’t want that, they can opt-out by not using > readonly. The guarantee only holds in combination with > readonly. > Alternatively, as you proposed, using methods (which I think would really be a better fit; > alternatively virtual properties which also will not support > readonly. > > With what we have now, both “camps" will be able to achieve what they want > transparently. > And I believe that’s a good middle ground we should go forward with. > > *Cheers,* > Nick Hey Nick, After sleeping on it, I think I agree with this assessment. For backed properties, especially, it makes sense that the value feels "immutable". If and when we get to virtual properties, maybe not. But that's a bridge to cross later. — Rob