Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123459
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-491-g033e30d24-fm-20240520.001-g033e30d2
Precedence: bulk
MIME-Version: 1.0
Message-ID: <bbdc5bf0-2516-4cb4-96f1-86393c22641c@app.fastmail.com>
In-Reply-To: 
 <CAB-Bujb7MJ_+t7F1=EF5gKTgKsm44JnAUinN4nnwBf52q1iwrg@mail.gmail.com>
References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com>
 <CAB-Bujb7MJ_+t7F1=EF5gKTgKsm44JnAUinN4nnwBf52q1iwrg@mail.gmail.com>
Date: Wed, 29 May 2024 20:02:54 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2
Content-Type: text/plain
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, May 29, 2024, at 7:53 PM, Andreas Hennings wrote:
> Hello Larry,
> just a quick thought.
> Is there a reason why we cannot just make it "public private string
> $x" instead of "public private(set) string $x"?
> We would define that the second visibility specifier is for write.
>
> The current proposal with "public private(set)" is less ambiguous, and
> it is immediately obvious that this is something new, and not just
> somebody accidentally added two modifiers.
> At the same time, it feels a bit alien and cluttered.
>
> Other options could be something like "public:private" or "public-private".
>
> A consequence of such options would be that you always need to specify
> the read visibility along with the write visibility.
> But this seems ok to me.
>
> This is not a final opinion, just a thought.
>
> -- Andreas

We went through a bunch of syntax variations last year, including "public private", "public:private", and "public private:set", plus a few others.  In an RCV poll, public private(set) was the favorite. (See link at the end of the RFC.)  It also allows for extension to other operations and scopes, and for the short-hand syntax.  Many of the other options did not support those.  Thus we stuck with the known syntax that had the most flexibility and most support.

By other operations, I mean, suppose we allow varying the visibility for obtaining a reference separate from a set (for some reason).  It's obvious how that would look with the current syntax: public protected(ref) private(set).  With "public private" or "public:private", it's really not clear how we'd even do that.

--Larry Garfield