Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118376
To: internals@lists.php.net
References: <ec4bc6e5-39ac-4a36-9d63-cca8dc6a29a6@www.fastmail.com>
Message-ID: <62F0628D.9060704@adviesenzo.nl>
Date: Mon, 8 Aug 2022 03:10:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <ec4bc6e5-39ac-4a36-9d63-cca8dc6a29a6@www.fastmail.com>
Content-Type: multipart/alternative;
 boundary="------------090406090200020907000202"
Subject: Re: [PHP-DEV] [RFC] Asymmetric visibility
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

--------------090406090200020907000202
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 5-8-2022 19:08, Larry Garfield 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.
>

For what it's worth, here's my initial thoughts after reading the RFC:

1. In "Permitted visibility, it explicitly states that the "set" scope 
MUST be more restrictive than the "get" scope. However, no reason for 
this is provided. Please make the argumentation to support this choice 
explicit.

2. In "Interaction with __set" and "Relationship with readonly" the RFC 
states it wants to be consistent with the readonly behaviour, but that 
is a different keyword. IMHO, these modifiers should work independently 
of each other and are now improperly closely binded. If one wants 
readonly behaviour, use the `readonly` keyword.

3. I only see a hat-tip to the property accessors RFC regarding the 
chosen syntax.
I'd like to see a more extensive discussion and consideration of various 
possible syntaxes.
Some potential alternatives:
- "visibility(get) visibility(set) type $prop" - which makes it explicit 
what each visibility applies to
- "visibility(set: visibility) type $prop" - where it is clear that the 
"main" visibility is the default and anything within the brackets a 
deviation. This syntax would also more easily allow for expanding, like 
"visibility(set: visibility, unset: visibility) type $prop"

I understand the desire for parallelism with Swift, but I don't think 
that's a valid argument. The syntax should be right for PHP and if that 
would happen to overlap/sync with a syntax used elsewhere: great, but 
that's not an argument to only look at that syntax without a proper 
discussion and due consideration for alternatives.

4. While I see no mention of "multi-property declarations", I presume 
the visibility would apply to all ? I think it would be good to mention 
this explicitly in the RFC as well.
     * By "multi-property declarations", I mean: `public string $type, 
$value = 'me', $somethingElse;

5. Are there tokenizer implications ? How will `set` (and possibly 
`get`) be tokenized ?

6. As this is something which can already be handled via magic methods, 
is there sufficient reason to make the language/engine more complicated 
to support this via a syntax ?

Overall, I mainly just see an idea in the RFC, but no justification for 
the need for it, let alone for any of the choices made.

Smile,
Juliette

--------------090406090200020907000202--