Re: [Vote] Asymmetric visibility v2
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
Thread (9 messages)