Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118358
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-758-ge0d20a54e1-fm-20220729.001-ge0d20a54
Mime-Version: 1.0
Message-ID: <e122e44f-550e-4089-8100-a27df9f8c9fa@www.fastmail.com>
In-Reply-To: 
 <CABdc3WqQ-kLTa3C=61_=yW-yJZuP2p_QW1TNe12WuHHur7aHng@mail.gmail.com>
References: <ec4bc6e5-39ac-4a36-9d63-cca8dc6a29a6@www.fastmail.com>
 <CABdc3WqQ-kLTa3C=61_=yW-yJZuP2p_QW1TNe12WuHHur7aHng@mail.gmail.com>
Date: Fri, 05 Aug 2022 14:51:41 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Asymmetric visibility
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Aug 5, 2022, at 2:27 PM, Micha=C5=82 Marcin Brzuchalski wrote:
> Hi Larry,
>
> pt., 5 sie 2022, 19:09 u=C5=BCytkownik Larry Garfield <larry@garfieldt=
ech.com>
> napisa=C5=82:
>
>> 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 fo=
r the
>> same.
>>
>
> Thanks for taking efforts on new RFC.
>
> Why not C# style property accessors? It feels more natural for me while
> Swift solution IMHO looks weird/odd composed with PHP class definition
> syntax. The arguments in favor from the RFC look forcibly (couldn't fi=
nd
> better word).
>
> Cheers,
> Micha=C5=82 Marcin Brzuchalski

There's a couple of reasons.  Ilija and I have spent quite a bit of time=
 brainstorming through accessors, and there's still a lot to finalize th=
ere, and lots of bikeshed potential.  It's a non-simple problem space.  =
However, asymmetric visibility is a good stand-alone concept that can wo=
rk without accessors, and has ample benefits of its own without accessor=
s, and has far less bikeshed potential.  (There's minor debates that mig=
ht be had over syntax, but the behavior is fairly "it is or it isn't".)

So the primary reason is that this syntax allows us to have asymmetric v=
isibility without having to think about accessors.  We can then, at some=
 point in the future, have a different discussion about accessors and no=
t have to worry about asymmetric visibility in the process.  The C# synt=
ax by nature only works if they come together in the same RFC, or at lea=
st one RFC is built such that it locks in some decisions for the other R=
FC.

As an example, one thing we've been discussing is if accessors should be=
 inline with the property (a la Swift and C#) or annotated methods (as i=
n Javascript and Python).  There's good arguments for both approaches, a=
s well as good arguments against.  But those would have *extremely* diff=
erent implications for how we represent asymmetric visibility.  So if we=
 took the C# style for asymmetric visibility, that would realistically l=
ock us into C# style accessors even before we've had the discussion abou=
t if we want that or not.  That's not good.

(Please don't anyone try to debate which accessor approach to take here;=
 the whole point is we want to introduce asymmetric visibility without h=
aving that debate yet.  We'll be able to have it in the future, I'm sure=
.  There's other knock-on effects as well that I'm skipping for now as n=
ot relevant.)

Keeping them separate also makes extending visibility rules in different=
 directions (as noted in the Future Scope section) at some point in the =
future can also be done without bumping into accessors.  Whether or not =
those directions are useful is a topic for another time, but it again al=
lows us to discuss those (like a "once" operation or a "package" scope, =
etc.) without worrying about the impact on accessors.

Secondarily, the C# style means you have to look both before and after t=
he property itself to know what its visibility rules are.  That's increa=
sed cognitive load.  This way, all of the various "flags" on a property =
remain in the same place, and presumably 99.999% of developers will put =
`public private(set)` right next to each other like that.  That makes th=
e visibility readable all from one spot, and if all you're using is that=
 and not accessors in the future, the impact on your existing reading sk=
ills is minimized.  This one is admittedly a bit more subjective, but re=
adability and cognitive load are certainly considerations to, er, consid=
er.

--Larry Garfield