Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124771
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 05 Aug 2024 10:42:09 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <d2fb7b73-8f48-4f33-8dca-9b7cd4c59b68@app.fastmail.com>
In-Reply-To: 
 <GV1PR01MB1052674102D22C0B3502B7BBFC2BE2@GV1PR01MB10526.eurprd01.prod.exchangelabs.com>
References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com>
 <b5c0be62-ea39-47fb-a8f8-ab6cd5ee3dab@app.fastmail.com>
 <CP8P284MB2148CB72E1A6A7AB5F29E8F093AE2@CP8P284MB2148.BRAP284.PROD.OUTLOOK.COM>
 <a3154cde-73ca-4b8e-bf90-b9aeabd5fbce@app.fastmail.com>
 <66c4ac1c-b3d7-4b20-b986-1fe1a464f485@app.fastmail.com>
 <GV1PR01MB1052674102D22C0B3502B7BBFC2BE2@GV1PR01MB10526.eurprd01.prod.exchangelabs.com>
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, Aug 5, 2024, at 7:27 AM, Vincent de Lau wrote:
> From: Rob Landers <rob@bottled.codes>=20
> Sent: Sunday, July 21, 2024 11:21 AM
>
>> On Sat, Jul 20, 2024, at 23:51, Larry Garfield wrote:
>> > On Sat, Jul 20, 2024, at 7:22 AM, Rodrigo Vieira wrote:
>> > > Will the alternative syntax on hook not even be put to a vote?
>
>> > It was, a year and a half ago when Aviz was first proposed.=C2=A0 T=
he preference was split, but leaned toward the prefix-style syntax.=C2=A0=
 So we went with that.=C2=A0 I don't think we'll ever get everyone to wa=
nt the same syntax, but we're using the one that was both somewhat more =
popular, and (as discussed in the RFC) arguably superior.
>
>> > As the "comments in yield from" thread has shown, *any* even slight=
 change to PHP's syntax will require work from static analysis tools.=C2=
=A0 That's the nature of the problem space, regardless of the syntax spe=
cifics.
>
>> Just to play devil=E2=80=99s advocate, it was also before we had prop=
erty hooks who advertised itself as a way to =E2=80=9Cwrap and guard acc=
ess to object properties=E2=80=9D but we are simply ignoring their exist=
ence here.
>
> I'm very disappointed that this discussion was not concluded before th=
e=20
> vote was started. One of the main arguments for picking this syntax is=20
> the research from two years ago, when hooks where not a thing. In my=20
> opinion that makes that whole research obsolete in this new context.=20
> I've asked to redo the research, but that was not acknowledged
>
> For the 'split visibility' concern, there has been some mentioning of=20
> reviving the `var` keyword, allowing you to place all visibility in th=
e=20
> hook block.
>
> While I don't have the 'perfect' syntax in mind, I strongly believe=20
> that this subject required a bit more investigation and discussion. My=20
> only hope now is that the people voting take this into consideration,=20
> especially as this is now being rushed into 8.4.

While hooks were not a feature when Aviz was first proposed, it was very=
 clear at the time that they were coming, and the syntax was mostly alre=
ady figured out, at least in broad strokes.  It's not like no one knew w=
e'd be having {} after the property if hooks pass.  I would not call the=
 results obsolete.  Rather, I think what it shows is that there's no syn=
tax that will satisfy everyone, so trying to find a syntax favored by ev=
eryone would just waste time and end in failure anyway.

I would hardly call this rushed; it was open for multiple months, and bu=
ilt on the previous discussion in 2023.  Lazy Objects, for instance, was=
 first proposed a month after aviz, and started its vote on the same day=
.  (No shade on Lazy Objects; I'm happy to see that passing.)

--Larry Garfield