Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124563
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-582-g5a02f8850-fm-20240719.002-g5a02f885
Precedence: bulk
MIME-Version: 1.0
Message-ID: <4de40957-9184-43ca-a7b9-4b325003d717@app.fastmail.com>
In-Reply-To: <e6ea3c7c-ccfe-4dca-94ff-3929223832e6@bastelstu.be>
References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com>
 <b5c0be62-ea39-47fb-a8f8-ab6cd5ee3dab@app.fastmail.com>
 <e6ea3c7c-ccfe-4dca-94ff-3929223832e6@bastelstu.be>
Date: Tue, 23 Jul 2024 16:45:20 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Jul 22, 2024, at 7:07 PM, Tim D=C3=BCsterhus wrote:
> Hi
>
> On 7/20/24 03:14, Larry Garfield wrote:
>> Baring any new developments, we plan to start the vote early next wee=
k.
>
> I've went through the RFC once more. I have the following remarks:
>
>> For that reason, a private(set) property is automatically final and m=
ay not be redeclared at all.
>>=20
>
> I assume that explicitly marking it as final is still allowed (just=20
> redundant)?

Correct.  I have added a comment to that effect.

>> There is one caveat regarding virtual properties that have no set ope=
ration. If there is no set operation defined on a property, then it is n=
onsensical to specify a visibility for it. That case will trigger a comp=
ile error. For example:
>>=20
>
> How does this interact with inheritance? Consider the following exampl=
e:
>
>      class P {
>          public $answer { get =3D> 42; }
>      }
>
>      class C extends P {
>          public protected(set) $answer { get =3D> 42; set =3D> 'dummy'=
; }
>      }
>
> This could be considered to be both narrowing the `set` visibility fro=
m=20
> `public` to `protected` (which is unsound), but also widening it from=20
> =E2=80=9Cnever=E2=80=9D to `protected` (which would be sound).

I checked with Ilija, and confirmed that it's the second.  I have update=
d the RFC accordingly to make that explicit.

>> as it's possible now for a property to be visible but not writeable. =
For the time being,
>
> I dislike the =E2=80=9Cfor the time being=E2=80=9D phrasing, because c=
hanging that would=20
> effectively result in a breaking change, because the __set() may be=20
> called in situations that were not anticipated. I would have preferred=
 a=20
> stronger phrasing that makes it clear that the RFC authors know what=20
> they are talking about.
>
> Best regards
> Tim D=C3=BCsterhus

I wordsmithed this a bit further.  We're not trying to be wishy-washy.  =
Rather, there are a couple of knock-on implications that are worth discu=
ssing that we consider off topic, but the approach we're taking does not=
 preclude them.  We're deliberately taking the conservative approach.  A=
dding a __set fallback in the future would not be a BC break, as it woul=
d be changing a hard error condition to a legal condition, which is some=
thing nearly all new features do.  We don't think it's wise to do that, =
but if someone wanted to advocate for that in the future we're not precl=
uding it.  If none of those further discussions happen, we still conside=
r this behavior complete and acceptable.

--Larry Garfield