Re: [RFC] Readonly property hooks

> On 11. Jul 2025, at 13:02, Rob Landers <rob@bottled.codes> wrote: >> >> Please remember that the RFC will allow readonly on backed >> properties only, not on virtual hooked properties. >> Nothing from your example would work, and it would result in: >> Fatal error: Hooked virtual properties cannot be declared readonly >> My proposed alternative implementation with caching addresses the concern Claude and Tim >> had and will make this hold: >> >> ```php >> class Unusual >> { >> public function __construct( >> public readonly int $value { >> get => $this->value * random_int(1, 100); >> } >> ) {} >> } >> >> $unusual = new Unusual(1); >> var_dump($unusual->value === $unusual->value); // true >> ``` >> >> – Nick > > Hey Nick, > > I was merely illustrating the different types, you can simply replace them with non-virtual > examples. To your idea of forced memoization, I'm not sure that's a good idea. In cases > where its a single execution context per request, it may be fine, but in cases of worker mode on > frankenphp, where readonly objects may live for quite awhile, it may not be. Generally, memoization > is an optimization, not a property of a value. > > In your example above, this breaks the principle of least astonishment, and potentially > violates referential transparency due to the calculation being non-pure. Referential transparency > basically says we can can replace the use of the variable with it's value (in this case, > $ususual->value with $unusual->backing_value * random_int(1, 100)). If it is memoized, we > cannot. There isn't a way to express that it is one value the first time (random) and a > different value the next time (the previous computation). This is a bit dangerous because the > programmer has no way to reliably reason about the code as if the expression can be substituted > freely. > > — Rob Hey Rob, 1) Well, we cannot have it both in the same time. Either we want a strict guarantee that the value doesn’t change after the first get hook call on a readonly property, or we want the opposite. So the proposed solution now is to be strict by default. If you want it non-cached you can use non readonly. 2) The same point could be made outside of "readonly hooks", for everything with any kind of randomness or external state (database, filesystem, …) source. That’s the trade-off. I find it very acceptable as a solution for the concern brought up by Claude and Tim. Cheers, Nick Aside: I just learned about your “records” RFC. Good stuff!