Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118418
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-811-gb808317eab-fm-20220801.001-gb808317e
Mime-Version: 1.0
Message-ID: <483e87df-61f9-4cb4-b3ce-03b8f8d81d25@www.fastmail.com>
In-Reply-To: 
 <CAOWwgpmee-vfAWsPkiSu826ST_vt8Nkp1Kp=ALH5WdXh6=7G0Q@mail.gmail.com>
References: <ec4bc6e5-39ac-4a36-9d63-cca8dc6a29a6@www.fastmail.com>
 <CAOWwgpmee-vfAWsPkiSu826ST_vt8Nkp1Kp=ALH5WdXh6=7G0Q@mail.gmail.com>
Date: Thu, 11 Aug 2022 13:54:34 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Asymmetric visibility
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Aug 11, 2022, at 8:48 AM, Nicolas Grekas wrote:
>> Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3:
>> Asymmetric Visibility.
>>
>> https://wiki.php.net/rfc/asymmetric-visibility
>>
>> Details are in the RFC, but it's largely a copy of Swift's support for the
>> same.
>>
>
> Thank you Larry and Ilija for this RFC.
>
> After reading it, I'm wondering about inheritance rules. What would be the
> rules when redeclaring an existing asymmetric property in a child class?
> The RFC should mention them I believe.

Yeah, Ilija is working on that still, I believe.  I believe the plan is, as with properties now, to allow widening access but not narrowing.  static properties will also be supported, but that implementation is WIP.

> But I'm also wondering about the use case where asymmetry would be useful
> in practice now that we have readonly?
> I voted against readonly at the time because it didn't address cloning, and
> also because it deprives end-users vs code authors IMHO (alike "final"). I
> would have very much prefered asymmetric visibility back then. But now that
> we are here, what are the use cases? If it's cloning only, then I would
> very much prefer finding a way to fix it rather than providing two subtly
> different ways to achieve the same thing.
>
> Eg can't we allow __clone methods to bypass the readonly restrictions? The
> engine already handles "guards" when using magic property accessors. Can't
> we use something similar for clone?
>
> And if yes, what would remain of the motivations for the asymmetric RFC?
>
> Cheers,
> Nicolas

There's a couple of use cases I see off hand:

1) Cloneability, as you've noted.

2) Fixing inheritance with readonly.  Right now, readonly is only settable from private scope, not protected.  So child classes are SOL.

3) A property that is rebuild based on other properties.  Eg, public private(set) $fullName, which is updated internally whenever $o->setFirstName() or $o->setLastName() are called.  (Or with accessor hooks in the future, which is on the roadmap.)

There's likely others, too.

I would also have rather had AV in the first place rather than readonly, as readonly is now getting in the way. :-(  But there are things readonly cannot reasonably do, and that's made worse by bad assumptions that static analysis tools have made about its usage.

We're working on a response to some other points made, but want to get on the same page with some more details first.  Stay tuned for a follow up.

--Larry Garfield