On Tue, Jul 22, 2025, at 11:18, Claude Pache wrote:
>
>
>> Le 22 juil. 2025 à 09:43, Rob Landers <rob@bottled.codes> a écrit :
>>
>> You can also implement this today, without using readonly:
>>
>> class Foo {
>> public int $bar {
>> get => $this->bar;
>> set => empty($this->bar) ? $this->bar = $value : throw new
>> LogicException("nope");
>> }
>> }
>>
>> https://3v4l.org/2JagR#v8.4.10
>>
>
> Your code is buggy, because `0` is “empty”:
>
> https://3v4l.org/iUPvW#v8.4.10
I wrote it over 30s while getting ready to walk out the door for a week long
vacation, so I won’t be entirely surprised if it is wrong. :)
>
>> Should I be able to mark this class as readonly? I would think so.
>
> I don’t think so.
>
> If you want to *document* the intended invariant, you can put a @readonly tag
> in a phpdoc comment.
>
> Adding a `readonly` keyword should *enforce* the invariant; the added value
> is that it would choke on bugs like the one you wrote just above, making it
> debugging much easier.
I’m not sure if you meant to, but I feel like you just argued for allowing
readonly on hooks so that these kinds of bugs aren’t accidentally written…
>
>
>> The readonly keyword simplified that greatly, however, readonly has been
>> neutered compared to regular classes in the last couple of versions. There
>> are so many edge cases and non-implemented features with them -- mostly due
>> to this exact argument you are making -- that they're nearly worthless to
>> actually define immutable value objects in today's PHP.
>>
>
> There are several issues with the readonly feature, mostly because of the
> “worse-is-better” philosophy. But we can slowly correct the main issues
> instead of making them worse.
>
> —Claude
I think this is the main crux of the issue, right? There is one camp that says
readonly means immutable and another that says readonly is read-only. These two
viewpoints are not compatible despite having a lot of overlap.
— Rob
