Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118370
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-758-ge0d20a54e1-fm-20220729.001-ge0d20a54
Mime-Version: 1.0
Message-ID: <a6bc6a0a-912e-4c0f-9571-7fb920f1d90c@www.fastmail.com>
In-Reply-To: 
 <CANS-=pfq1Q+aK6CWTGKpiSH_M4PABQwb-65HqznDw_xzoDM8+Q@mail.gmail.com>
References: <ec4bc6e5-39ac-4a36-9d63-cca8dc6a29a6@www.fastmail.com>
 <CABdc3WqQ-kLTa3C=61_=yW-yJZuP2p_QW1TNe12WuHHur7aHng@mail.gmail.com>
 <e122e44f-550e-4089-8100-a27df9f8c9fa@www.fastmail.com>
 <CAKxcST_Mu3qDKKLgtsBBVAm=6mLirhjZ-88f+jjWeNhWyzO16A@mail.gmail.com>
 <A78DA1F7-1F74-4A94-962C-0EA5979431AD@gmail.com>
 <CANS-=pfq1Q+aK6CWTGKpiSH_M4PABQwb-65HqznDw_xzoDM8+Q@mail.gmail.com>
Date: Sun, 07 Aug 2022 14:01:55 -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 Sun, Aug 7, 2022, at 5:54 AM, Lynn wrote:
> On Sun, Aug 7, 2022 at 12:34 PM Rowan Tommins <rowan.collins@gmail.com>
> wrote:
>
>> Can you expand on where you think the ambiguity / implicitness is? As I
>> understand it, the RFC is proposing exactly three new combined access
>> levels:
>>
>> - "public private(set)"
>> - "public protected(set)"
>> - "protected private(set)"
>>
>> Although aesthetically it will take a bit of getting used to, it seems to
>> me pretty clear that the first means "mostly public, but private if you
>> want to set it", and so on.
>>
>> The only thing I can think of that could be described as "implicit" is
>> that accessing a property by reference is considered a "set" operation,
>> which I'm not sure how any implementation could avoid.
>
>
> Personally for me it's the syntax. Reading "public private", "public
> protected", or "protected private" reads really weird `public private(set)
> static self $property`. In the end it makes sense if you know what it
> means, otherwise it's probably confusing. I really like this RFC and I feel
> like this might just be the way to go forward, but I have my doubts about
> how many more keywords can be realistically added before it becomes a
> problem.

What syntax would avoid having the visibility keyword repeated?  if you want "public get, private set" behavior, I don't know how that could be done without having the words "public" and "private" both appear somewhere.

Also note, since using private(set) is mutually exclusive with readonly, that the resulting keyword list is about the same length as the existing "public readonly string $foo" that has cropped up frequently with PHP 8.1.  So... yes it's another keyword, but it's not more keywords that can exist simultaneously.  And moving the keyword to the right (a la C#) wouldn't make it any shorter; if anything it would be even more keystrokes.

Very close in size, same in complexity:

public readonly string $foo
public private(set) string $foo

--Larry Garfield