> 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:
> 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".
> Memoization (expensiveCalculation): only calculate the property once and only
> once. This is a performance optimization. It is still "readonly".
> 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
