> Le 3 juil. 2024 à 14:42, Rob Landers <rob@bottled.codes> a écrit :
>
> On Wed, Jul 3, 2024, at 14:28, Claude Pache wrote:
>>
>>
>>> Le 3 juil. 2024 à 11:54, Claude Pache <claude.pa...@gmail.com> a écrit :
>>>
>>>
>>> 2. As for readonly, I think that the invariant it is supposed to provide
>>> should be enforced as strictly as possible. It means that `readonly` is
>>> only acceptable if there is no `get` hook.
>>
>> Hi,
>>
>> One more thing, why I think that we should be strict here. It is not just
>> for preventing the user to write *dumb* code, it is also for preventing them
>> to write *creative* code, e.g.
>>
>> ```php
>> class doc {
>> public readonly int page {
>> get => $this->page + $this->offset;
>> }
>> private int $offset = 0;
>> public function __construct(int $page) {
>> $this->page = $page;
>> }
>> public function foo() {
>> // $this->offset may be adjusted here
>> }
>> }
>> ```
>>
>> —Claude
>
> I don't see anything wrong with that code. $page doesn't say "immutable" it
> says "readonly", as in "cannot write to".
>
> — Rob
The fact you don’t see anything wrong is *precisely* the issue. According to
the original RFC [1], the intention of readonly properties was immutability,
not just non-writability. For the weaker case of non-writability, it was
explicitly mentioned the possibility of (future) asymmetric property visibility.
That said, I agree that “immutable” would have been a better word choice than
“readonly” for conveying the original intention. We could also ignore the
original intention and reinterpret the feature in case everyone agrees
(personally, I prefer the original intention, but I won’t fight for that).
—Claude
[1]: https://wiki.php.net/rfc/readonly_properties_v2#rationale
