On Sat, Jul 19, 2025, at 03:04, Claude Pache wrote:
>
>
>
>> Le 19 juil. 2025 à 00:41, Rob Landers <rob@bottled.codes> a écrit :
>>
>> The original author (Nikita) suggested that there's nothing in the original
>> design that precludes accessors -- and highlights languages where there are
>> both and they are doing just fine more than 5 years later.
>>
>
> Hi Rob,
>
> It is indeed entirely reasonable to have both readonly properties and hooked
> properties (aka accessors), and today PHP has indeed both of them (and even
> asymmetric visibility on top of that, as a separate feature contrarily to
> C#). But it doesn’t mean that it is reasonable for the *same* property to be
> *both* readonly and hooked, which is the point that is currently disputed. —
> What do the other languages allow? Is it possible to define a readonly
> property with a user-defined getter? (Disclaimer: Even if one of them allows
> such a thing, I’ll still think that it is a bad idea.)
>
> —Claude
Hey Claude,
>From what I've seen in other languages, this combination is fairly common and
>not inherently poblematic.
- C# allows get hooks with user-defined logic, even in readonly structs.
- Kotlin uses val with a get() body, which is readonly from the consumer's
perspective, even though the value is computed.
- TypeScript allows a get-only accessor which acts readonly.
- Swift also allows get-only computed accessors/hooks.
Most languages treat these as an abstraction boundary: allowing you to expose
computed state while still guaranteeing external immutability.
This RFC is proposing something similar: the public surface is observably
immutable, even if a value is derived. We can already do this today with more
boilerplate:
class Foo {
public function __construct(private readonly int $_bar) {}
public int $bar { get => $this->_bar * 2; }
}
The RFC reduces that boilerplate and clarifies intent. In the example above,
there is nothing mutable about it. It is "read only" from a public contract
point-of-view, we just can't mark it as a readonly class.
As for side-effects or non-determinism, that is a valid concern, but one that
applies to any property hook and non-scalar property. A readonly declaration
doesn't necessarily encourage or prevent that, it simply declares that the
instance state cannot be mutated after construction.
I'd argue the RFC aligns well with the conventions and capabilities of other
languages, and builds on what PHP already allows.
— Rob
