On Mon, Aug 5, 2024, at 8:49 AM, Theodore Brown wrote:
> On Fri, July 26, 2024 at 12:25 Larry Garfield wrote:
>
>> Voting for Asymmetric Visibility is now open.
>>
>> https://wiki.php.net/rfc/asymmetric-visibility-v2
>
> Hi Larry and Ilija,
>
> Thank you for all your work on this RFC!
>
> One part that doesn't make sense to me is this sentence near the end in
> the "Readonly is incompatible with inheritance" section:
>
>> With asymmetric visibility, the `readonly` usage here can be replaced with `protected protected(set)` or `readonly protected protected(set)`, avoiding the need to double-declare properties.
>
> `protected protected(set)` just removes readonly, and is the same as
> `protected`, right? So couldn't such a change be done now without
> asymmetric visibility?
>
> And the change to `protected protected(set) readonly` as shown in the
> example also seems unnecessary, since earlier in the RFC it says that
> readonly will be changed to imply `protected(set)` rather than
> `private(set)`. So it seems that no change is needed to the abstract
> class here - the properties can remain `protected readonly`, and the
> implementation can be simplified since readonly properties will now
> imply `protected(set)`.
>
> Or have I misunderstood something here?
I believe in this case you're correct. That example was written early on, before we decided to expand readonly to protected(set) by default. I didn't realize that needed to be updated as well. Yes, in this case, the widening of readonly would also resolve that issue. `protected protected(set)` would now be redundant, but not hurt anything, whereas `protected private(set)` would have an effect. `public public(set) readonly` would also be legal (though I don't personally know why you'd do that, there's no inherent reason to make it illegal).
--Larry Garfield
