Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118369
MIME-Version: 1.0
References: <ec4bc6e5-39ac-4a36-9d63-cca8dc6a29a6@www.fastmail.com>
In-Reply-To: <ec4bc6e5-39ac-4a36-9d63-cca8dc6a29a6@www.fastmail.com>
Date: Sun, 7 Aug 2022 21:59:50 +0300
Message-ID: <CAAwdEzAwghtdCQWp+-=acSiWruEViNO17+x0aPQPNXZRe9DJww@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c11a3b05e5ab4ed5"
Subject: Re: [PHP-DEV] [RFC] Asymmetric visibility
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--000000000000c11a3b05e5ab4ed5
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 5, 2022 at 8:09 PM Larry Garfield <larry@garfieldtech.com>
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.
>
> --
>   Larry Garfield
>   larry@garfieldtech.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Hi Larry, Ilija,

Review the proposal and it looks great.

I have a few subjects to point and maybe discuss further if you think so:

1. The first subject is visible even from the first phrase of the RFC that
uses both the terms "get and set operations" and "read and write
operations".
I'm wondering if you thought about using protected(write) or private(write).

2. The term "asymmetric visibility" is not that accurate and I believe
"asymmetric access" or "asymmetric accessibility" would fit better.
As noted in the relation with __set(), a public private(set) property that
is attempted to be written from global context will not act like it's not
visible but that it's not accessible for writing.

3. I assume the target is both static and non-static properties.
This should be mentioned in the RFC.

Regards,
Alex

--000000000000c11a3b05e5ab4ed5--