Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118375
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-758-ge0d20a54e1-fm-20220729.001-ge0d20a54
Mime-Version: 1.0
Message-ID: <23a5ca61-a4d9-4a39-9364-2fdd1688f918@www.fastmail.com>
In-Reply-To: <af4c6a1b-b1d1-4e2d-b8fa-7517da906c6a@www.fastmail.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>
 <578bd2ba-1594-fa0b-0f8b-3734af1f0383@gmail.com>
 <af4c6a1b-b1d1-4e2d-b8fa-7517da906c6a@www.fastmail.com>
Date: Sun, 07 Aug 2022 16:48:11 -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 3:46 PM, Ollie Read wrote:


> Just to throw in my ten cents:
>
> I'm not sure if this is because I was recently reading about the fact 
> that PHP doesn't have proper support for a comma operator, but I quite 
> like the idea of providing them as a comma-separated list.
>
> // Public for get and set
> public int $number
>
> // Public get, private set
> public, private int $number
>
> If a single visibility is provided, same old same old, but if two are 
> provided, they are in the order of get, followed by set. While not 
> being as verbose as providing (set) or other markings to differentiate 
> them, it feels more natural, and it doesn't overcomplicate it.
>
> ---
> Best Regards,
> *Ollie Read*

I'm not wild about implicit ordering as a syntax, for two main reasons:

1) It requires implicit knowledge on the part of the reader what's going on.  Any kind of explicit syntax makes it clear "public, except for this operation".  ("this operation" for now being just set, but then the set is right there and self-documenting.)

2) It makes extending it to other operations like "once" or "init" in the future impossible.  (See Future Scope.)  If we went with public, private string $foo, which implicitly meant "public(get), private(set)", and then in the future we add a "once" operation to mimic the behavior of readonly... what would that look like?  With (set), it's self-evident how to extend the syntax.  With it being fully implicit, I cannot think of a way to do so.

Something like public private:set (colon instead of parens) would work just as well, if the () are confusing somehow, but that doesn't feel like a common problem.  And it would lose the parallelism with Swift.

--Larry Garfield