Hey Larry, Thanks for your answer.
> On 2. Jun 2025, at 21:39, Larry Garfield <la...@garfieldtech.com> wrote: > This was discussed heavily in the design and discussion phase for hooks. The > main problem is that the expectations for readonly and the expectations for > hooks don't always align. For example, if a virtual property has a get-hook, > can it be readonly? We cannot guarantee that the property will always return > the same value, but that is rather the expectation of readonly. For me, `readonly` is relevant for set operations. It gives me certainty that a value can only ever be set once. I don’t see how it must be related to retrieving a value. > Given how large and complex the RFC was already, we collectively decided to > punt on that question until later. Ilija and I did tepidly propose loosening > the restriction slightly: > > https://wiki.php.net/rfc/readonly_hooks > > Though we've not gotten back to it as we've both been busy and there hasn't > been a ton of calls for it, and it likely still needs to be tweaked some. Yeah, so here I am, with a call after the feature was in the wild for a while. Hoping that others might chime in with their own experiences and opinions. I wasn’t aware of this follow up RFC exists. Excited to see it! Limiting it to backed properties feels sensible. I guess it still would solve the majority of use-cases already. Especially around dumb value objects. I would like to add, personally, I don’t believe the above is dumb: ```php class Dumb { public readonly int $value { get => $this->value * random_int(1, 100); } } ``` I think it is a legitimate use-case. Why wouldn’t a `readonly` property allow us to format, cast or however mutate a “only once written value” on consumption? It will not change the underlying value. If it makes things easier for us, allow it. It’s not like this is some hidden implicit behaviour. We consciously must add the extra code, hence expect the output to be changed accordingly. So, I would love to see this RFC to be implemented. Maybe you want to move it to discussion? Then my separate thread here would be obsolete. > Another possibility might be to have the readonly marker on a class just skip > applying to virtual properties. So you cannot specify it explicitly, but a > class-level readonly no longer causes a conflict. I don't know how viable > that is off hand. I don’t have a strong opinion on virtual properties. At first glance this feels too implicit to me. Given their complexity, rather not allow it for virtual properties (for now). We can use getter methods for that. The follow up RFC is good as is and a low-hanging fruit with high positive impact, if you ask me. -- Cheers & thanks, Nick
