Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124509
Date: Sat, 20 Jul 2024 09:22:19 -0300
To: php internals <internals@lists.php.net>, Larry Garfield
 <larry@garfieldtech.com>
Message-ID:
 <CP8P284MB2148CB72E1A6A7AB5F29E8F093AE2@CP8P284MB2148.BRAP284.PROD.OUTLOOK.COM>
In-Reply-To: <b5c0be62-ea39-47fb-a8f8-ab6cd5ee3dab@app.fastmail.com>
References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com>
 <b5c0be62-ea39-47fb-a8f8-ab6cd5ee3dab@app.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2
Content-Type: multipart/alternative; boundary="669bac00_44b1ab07_4d0"
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CP8P284MB2148:EE_|CP4P284MB2368:EE_
X-MS-Office365-Filtering-Correlation-Id: b29177e9-0bb3-4398-fd7e-08dca8b69dd7
X-Microsoft-Antispam:
	BCL:0;ARA:14566002|461199028|19110799003|8060799006|440099028|4302099013|3412199025|56899033|1602099012;
X-Microsoft-Antispam-Message-Info:
	hF63pxbBegvPorrVnaN/VYhvaFgkW3vcs6qcREc6wNxoStN7WJuGnyzGLpwHFnNiUwhegSh/0RUV4uFTLChwBE4IXovD+VTDSgD+YAIzMlfeiXar1+1NR9FSlzDr7tdfCaiX7Yg5+nGzRIgwhg32WeiAl4fKJA7O3AWWKi51FL4VUxZC1xjzOpxsTzL0csbEoXTKc6owoGO/8cw0wAsh8khm3gzTe6JzTKZFSD/pL9KelxP8OgV63tJ1DPwJ4dw0bTuRts3nJtGI83ZtQY50RqvWJow3B05y0aUpBcdXYOde3IZu3BjwxDorQhJg7tAxXHDIueimbwW6063TZNTGs7DQDqxILrbCbMn8RSOVWtECARFrEKkt9K9a0qQkGzYksuIstU2umVJCye+X7ACTe+8ptOqFhc2wpVBLlnigPmGHXKPEm4cYyJiqpshN5z78HoBf8+o5JHVKBPx6Zb0tCACdZ3OTLD9uvmSiC0dA20dbLGAuD7TmtwbZvqObzypUo2OgzOM34+Q5olTy2TLV9BznUsXR1yyb0GwO9xNqONw/kGwSWctYPZa6IAKCjtWyIvGw4mKdPkKfQ0eZMlJ7bg7i5fPUx0CaCHF30FVF/MyfzXfC9Ax7k5rCPe7K/QeXBEaHgeU+nEFuGTw+GMfsSoLF1oKWR+Pky/eCraKV8xmzGBZOHkAsW9I05GbpEu7+4HJtGYKduyyd2rOqNx4ZffjGK7Daz77k1xcxjZdGEvMcqvQ3tR4iVOBpJBKaDWpz
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?VjgydTRteGlUem5jNmU4YTdlM3Q3bDI4NFRleTYyQWg1aldISy9CTjUySnM5?=
 =?utf-8?B?ZmFob29BR3dNL0o5dEQxTGxrVlIwYXJia2ZmRlZIZ092S3JPU1hBY3ZPV1Yy?=
 =?utf-8?B?b20raVlxbGZ2NWFEOFA4YTlOdjZDSjJMR1hySkZCL0hNUzI0TmNrNjR6U1Nw?=
 =?utf-8?B?ODVkdk0vLzhrUDlTaGRwMTNJbkkxbXVGWTFGMXpIVHdRRW5HZDRocnVQTEtY?=
 =?utf-8?B?MGhhOGJPaG13QjRUVzBUeGdST1lCK1dOMlN4alBNN1d5ODBkd053WkpwczR5?=
 =?utf-8?B?WjVoQkJ1U2NzZGtvZ1RadnBXUnNyc05HRmRwZ0pURjgyeUp4YXNiTkJyWCtR?=
 =?utf-8?B?WHlCRDdmZURWdWp1QnplZmhkV0RvZmdiZDYwb3J6Mkp5WlNPdlVLY3B2RlBh?=
 =?utf-8?B?N0w3US9FNTdKNzVOUVZnRVp2eGkrOVpHNEFaMTFPUzd4L2psdFAxdDZLMWJl?=
 =?utf-8?B?Sjh2Q01XQWhwQit4cmZuaUxEbXVhbitxNDdETE1UTXpxNE0yMkJaYmpqaHZt?=
 =?utf-8?B?K0lxTnZYVXpBbFZBOXg3NkUrbGZPMlA4YkdYc3U4NGRDZGpBKzZRR1JpUmRL?=
 =?utf-8?B?c2VjYVVWcHVVdStYQkZ4Z3F6MlJha3dMUTViaGNEeGVFNDhYK29IL1NSOVZS?=
 =?utf-8?B?WUhOa05lbnF5eFlYRGtOMDBKcHFOczFMOHFnVjVYNjVQeThFRXEvbUFTK0Mr?=
 =?utf-8?B?UGg5SUdOaWphemUwbTFKcUVSY0QveWlnczdEekRSMEVnbGJNTDZJTGw0S2FD?=
 =?utf-8?B?Z3ZkazQ1clcxYWtXQVJlVHU0NlpFczBmc29aYmk2dHozSnRMQ2lyZDMwTEJI?=
 =?utf-8?B?QVdjYzRoMEgyU0Z1NmxLQ1pLL0E3QjMwcVVyRU9mK1YzTE53amxYSmNPVlpH?=
 =?utf-8?B?OUxoNmhJNXorS2JMSzV0WnBlSUhvQmhlaXJaYStjaHIvSjVrOWZJVm9WOEt1?=
 =?utf-8?B?NVovRmEzM25yWC9ialRkOW9mNkxpdlpZSDM5WTJndktIdmNXNjM0Sm1URGlh?=
 =?utf-8?B?UGo4KzRtb1ZCeXdLYm43MHVJL3Q4M0l4eUMrYmZ1SU1WZW4zSnZnNk5DbzZE?=
 =?utf-8?B?NXFyempnNjZhY1Y0d3RjWGpnWjhYanRYSS9MZTBXUTFXeWF1SVJBd1d2dVFD?=
 =?utf-8?B?WHp3NGI1d2JyQ1dsRElleFlyZGx2cENtTWNaUVRxTmdvMDhoQm5JaVd4KytO?=
 =?utf-8?B?Q2dxckVtZm8rVWQ5NE9pREpmZm1nNmdPUFhodHVSZFQ0bHdRSmVwZkErazdl?=
 =?utf-8?B?ZmZXS1I5Qy9Qamk4TWdCeDhIMzRSb1J6YVQrQkpxbUw4UXd4Nyt1bGpVUEt2?=
 =?utf-8?B?UFAwTjJvNU9BYVFIZkhNZkxjcFpBZ2NPT3cyODdQbXVjR0dTMThzVHVaT29U?=
 =?utf-8?B?QXdCSWpuWTAyblJHWDdVQ0c1bWtteE9pTlJzZ3RNYjI5eWNaZEVYNlNiRTlT?=
 =?utf-8?B?MFhGYjZ4d3cwMjNVYTc4UUZSVmhkLzM5OGZXTWhYS1VYekdoekxrZHZobjE4?=
 =?utf-8?B?WmxBOGRNcmo2K1FtSTdrZGp6NW5henh3Zkk5K0Fpc3d5cS80QXRXd3p5ajdN?=
 =?utf-8?B?NXpjWlJzL1AyTVdUVHpXbUhTK2JCS1FzeHRJVFNsVjRuTlR4eGtSY2tUKy83?=
 =?utf-8?B?WDRoQzYwd21CbkVFaWl0Qjd1cFhVeHZxTCtnZXpyMjQ2NSswaFhBK3NNamVG?=
 =?utf-8?Q?8Umf/d1v+jZh+Zlgx+Ua?=
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b29177e9-0bb3-4398-fd7e-08dca8b69dd7
X-MS-Exchange-CrossTenant-AuthSource: CP8P284MB2148.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2024 12:22:26.8487
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CP4P284MB2368
From: rodrigo.vieira92@outlook.com (Rodrigo Vieira)

--669bac00_44b1ab07_4d0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Will the alternative syntax on hook not even be put to a vote=3F

I think the =22prefix-style=22 syntax breaks the standard property signat=
ure template that exists since PHP 5=21

Natural syntax:

<visibility> <types> =24<name>;

With prefix-style:

<visibility> <visibility>(set) <types> =24<name>;

This introduces a syntax that is totally unexpected to natural reading. I=
n my opinion, pretty ugly.

What about some static code analysis tools=3F What about using regex to p=
arse code and syntax in PHP (which takes a lot of work to build) for exte=
nsions used in IDEs like VSCode, IntelliJ, etc.=3F
To parse Property Hooks, a lot of time and work will already be spent ada=
pting to the new syntax, and now this as well=3F Why not take advantage o=
f the new Property Hooks syntax newly implemented=3F

Implementing visibility in the hook, which can be now the default API of =
the properties, would further enhance the syntax of Property Hooks, which=
 in my opinion is one of the best features of PHP in the past five years.=


If more operations on Hooks are implemented in the future, what is the us=
e of this syntax=3F How could it be used=3F =46or example, an operation t=
hat is called only when a property is first set: =60init=60 hook.

public =24prop =7B
=C2=A0 =C2=A0private init =3D> //...set a default initial value here
=7D

A hook called 'push' only for arrays, would solve some semantic problems =
and make it clear to separate the set operation (set values of an array) =
vs push only one item to the array as I showed in the example above.

What about other operations that are already common when we use magical m=
ethods in the future: unset, isset, etc.=3F
In the Property Hooks R=46C, it was mentioned that more hooks may be adde=
d in the future.

It may be a default behavior for developers to want to override all magic=
 methods for properties using Property Hooks. =46or now there is only get=
 and set, but what about unset, isset, etc=3F How is it to define the vis=
ibility for this in the future=3F

public private(set, unset)....
=3F=3F
Where would new operations beyond the =60set=60 will enter this syntax=3F=


Cheers,
Rodrigo Vieira
Em Jul 19, 2024, 10:18 PM -0300, Larry Garfield <larry=40garfieldtech.com=
> escreveu:
> On Wed, May 29, 2024, at 2:15 PM, Larry Garfield wrote:
> > As promised, Ilija and I offer this revised version of asymmetric vis=
ibility.
> >
> > https://wiki.php.net/rfc/asymmetric-visibility-v2
> >
> > It's still essentially the same as last year's version, but with a fe=
w
> > adjustments and changes:
> >
> > * readonly properties are now supported in a logical fashion.
> > * We've brought back the abbreviated form, as public-read, something
> > else set is the most common use case.
> > * The section on magic methods has been greatly simplified. The
> > implementation itself hasn't changed, but the explanation is a lot le=
ss
> > confusing now.
> > * We've explained how aviz interacts with hooks (they don't, really)
> > and with interface properties (in the obvious way), which didn't exis=
t
> > at the time of the last draft.
> > * We've added a section with examples of how aviz is a concrete
> > improvement, even in a world with readonly and hooks.
> > * We've added a section discussing why the prefix-style syntax was
> > chosen.
>
> Hi folks. After a side quest to polish off hooks, we're nearly ready to=
 bring aviz to a vote.
>
> We've made one change since we last discussed it: Specifically, Ilija r=
ealized that =5F=5Fset's behavior is already inconsistent, so supporting =
it for aviz properties with invisible set would make it even more inconsi=
stent, not less. =46or that reason, we've changed the =5F=5Fset behavior =
such that a non-readonly aviz property will not trigger =5F=5Fset. =46urt=
her details are in the R=46C, but in short, all of the use cases for that=
 behavior now have better alternatives, such as property types, hooks, an=
d aviz itself. So there's really no point to falling back to =5F=5Fset in=
 edge cases.
>
> https://wiki.php.net/rfc/asymmetric-visibility-v2=23interaction=5Fwith=5F=
set=5Fand=5Funset
>
> Baring any new developments, we plan to start the vote early next week.=

>
> Cheers.
>
> --Larry Garfield

--669bac00_44b1ab07_4d0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html xmlns=3D"http://www.w3.org/1999/xhtml"><head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8"><t=
itle></title>
</head>
<body>
<div name=3D"messageBodySection">
<div dir=3D"auto">Will the alternative syntax on hook not even be put to a =
vote?<br>
<br>
I think the &quot;prefix-style&quot; syntax breaks the standard property si=
gnature template that exists since PHP 5!<br>
<br>
Natural syntax:<br>
<br>
&lt;visibility&gt; &lt;types&gt; $&lt;name&gt;;<br>
<br>
With prefix-style:<br>
<br>
&lt;visibility&gt; &lt;visibility&gt;(set) &lt;types&gt; $&lt;name&gt;;<br>
<br>
This introduces a syntax that is totally unexpected to natural reading. In =
my opinion, pretty ugly.<br>
<br>
What about some static code analysis tools? What about using regex to parse=
 code and syntax in PHP (which takes a lot of work to build) for extensions=
 used in IDEs like VSCode, IntelliJ, etc.?<br>
To parse Property Hooks, a lot of time and work will already be spent adapt=
ing to the new syntax, and now this as well? Why not take advantage of the =
new Property Hooks syntax newly implemented?<br>
<br>
Implementing visibility in the hook, which can be now the default API of th=
e properties, would further enhance the syntax of Property Hooks, which in =
my opinion is one of the best features of PHP in the past five years.<br>
<br>
If more operations on Hooks are implemented in the future, what is the use =
of this syntax? How could it be used? For example, an operation that is cal=
led only when a property is first set: `init` hook.<br>
<br>
public $prop {<br>
&nbsp; &nbsp;private init =3D&gt; //...set a default initial value here<br>
}<br>
<br>
A hook called 'push' only for arrays, would solve some semantic problems an=
d make it clear to separate the set operation (set values of an array) vs p=
ush only one item to the array as I showed in the example above.<br>
<br>
What about other operations that are already common when we use magical met=
hods in the future: unset, isset, etc.?<br>
In the Property Hooks RFC, it was mentioned that more hooks may be added in=
 the future.<br>
<br>
It may be a default behavior for developers to want to override all magic m=
ethods for properties using Property Hooks. For now there is only get and s=
et, but what about unset, isset, etc? How is it to define the visibility fo=
r this in the future?<br>
<br>
public private(set, unset)....<br>
??<br>
Where would new operations beyond the `set` will enter this syntax?<br>
<br>
Cheers,<br>
Rodrigo Vieira</div>
</div>
<div name=3D"messageReplySection">Em Jul 19, 2024, 10:18 PM -0300, Larry Ga=
rfield &lt;larry@garfieldtech.com&gt; escreveu:<br>
<blockquote type=3D"cite">On Wed, May 29, 2024, at 2:15 PM, Larry Garfield =
wrote:<br>
<blockquote type=3D"cite" style=3D"border-left-color: grey; border-left-wid=
th: thin; border-left-style: solid; margin: 5px 5px;padding-left: 10px;">As=
 promised, Ilija and I offer this revised version of asymmetric visibility.=
<br>
<br>
https://wiki.php.net/rfc/asymmetric-visibility-v2<br>
<br>
It's still essentially the same as last year's version, but with a few<br>
adjustments and changes:<br>
<br>
* readonly properties are now supported in a logical fashion.<br>
* We've brought back the abbreviated form, as public-read, something<br>
else set is the most common use case.<br>
* The section on magic methods has been greatly simplified. The<br>
implementation itself hasn't changed, but the explanation is a lot less<br>
confusing now.<br>
* We've explained how aviz interacts with hooks (they don't, really)<br>
and with interface properties (in the obvious way), which didn't exist<br>
at the time of the last draft.<br>
* We've added a section with examples of how aviz is a concrete<br>
improvement, even in a world with readonly and hooks.<br>
* We've added a section discussing why the prefix-style syntax was<br>
chosen.<br></blockquote>
<br>
Hi folks. After a side quest to polish off hooks, we're nearly ready to bri=
ng aviz to a vote.<br>
<br>
We've made one change since we last discussed it: Specifically, Ilija reali=
zed that __set's behavior is already inconsistent, so supporting it for avi=
z properties with invisible set would make it even more inconsistent, not l=
ess. For that reason, we've changed the __set behavior such that a non-read=
only aviz property will not trigger __set. Further details are in the RFC, =
but in short, all of the use cases for that behavior now have better altern=
atives, such as property types, hooks, and aviz itself. So there's really n=
o point to falling back to __set in edge cases.<br>
<br>
https://wiki.php.net/rfc/asymmetric-visibility-v2#interaction_with_set_and_=
unset<br>
<br>
Baring any new developments, we plan to start the vote early next week.<br>
<br>
Cheers.<br>
<br>
--Larry Garfield<br></blockquote>
</div>
</body>
</html>

--669bac00_44b1ab07_4d0--