Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123569
Date: Mon, 10 Jun 2024 14:51:07 -0300
To: Larry Garfield <larry@garfieldtech.com>, Tiffany
 <tiffany.k.taylor@gmail.com>
Cc: php internals <internals@lists.php.net>
Message-ID:
 <CP8P284MB21480B5455D962823CF634C593C62@CP8P284MB2148.BRAP284.PROD.OUTLOOK.COM>
In-Reply-To: <CAHSBg45uKCO9R9nrF6c7D1oZsEEwUxkkiRtMoA4fk0ECY--ekw@mail.gmail.com>
References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com>
 <CAHSBg45uKCO9R9nrF6c7D1oZsEEwUxkkiRtMoA4fk0ECY--ekw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2
Content-Type: multipart/alternative; boundary="66673d11_4d64ce3a_3324"
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CP8P284MB2148:EE_|CP6P284MB1605:EE_
X-MS-Office365-Filtering-Correlation-Id: e9212af8-ae27-4481-99e9-08dc8975ee0c
X-Microsoft-Antispam:
	BCL:0;ARA:14566002|9400799015|461199019|440099019|3412199016|1602099003|56899024;
X-Microsoft-Antispam-Message-Info:
	22mVjy8LGIPzD9/eJS//b2BboCcuZUGCRJ/3VXQDz0CSwnv9D/UkNTgm7dLepwL58FDyKspoGe4l0BXkDKC5b7rLpHI93UplylRRDCiaZpg6Lb9tp1UbbW0tBW7rZ3FjXatpZLzFCptgBdJqDW761/3DvO/KrrcpJi4FfxXjxEoRsAVwxMgAxGpoasobZx6Wsy+bU7bxn8xHFxpvvWf0GpeIwHoOKsPAT/ekyEDv89TPCkusvWJTGRG6c2CKGB8xjlyjh6yIoNs1lXILzO0mhRnKYIzLIUDG5pLVHSK9heojvQxtj/8HyWwry2gXbeIJZtuKkULw6yPJHk9AoreZBz3r6Yvo1dkXsGKbTi20ZYs9VyoI0WPrWGeefzYgOApFqsTjHHOM+rfxIkAiTHfpuhD+osyRzy1vLSSGKxUF0jX3a+V9cwSJ1AnCCNENGceOzQbPkux04qST+XUDxFsyIscKLixpdIS6zWr8BdHbsqRbreSdL1aapk7OeeCZNXHFdPKKikPmDjbUuYABTQeNydCeCivAUpakrbXO84Sa5zzTLljmRmsqzQVDnmt9WEATjeatWs4DSH7QTb0ka4Vqt/fCj2erh2X+mMJXX/LgyM5D2AmTrZrvdigwF7hEEkWkkuD5YCmG7Oc0R1y5h3rRytETeUSAPQXZfjaI3nW1Eq9u+bqETrn/SfKSu2OPWYT+G0GnFaQyOQrvEKAjCWO20n8bgOfCdcftID2f0jvpYLriYx59kiBF+FsDa/1DQfmG
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?TFdpQnFpRVlMdnZEbmI4N2ZkNlZZYnhONFhKVldET1VFQlVkLzU0NXVHT3ZZ?=
 =?utf-8?B?d1l1TThSWmNhSUZpcWpQd0RKOTlpUk51bHNQbXN6MlVBb0J1RXgwNHRqRlVL?=
 =?utf-8?B?UEthUk85L1I3bk5nZUEzRFpFNVRzOHhLZ0N0aFlWTXl6dExYQk9WYUU2M0t6?=
 =?utf-8?B?dWR0aUNCS01sUGlYQlJ5WFJwTlVpWUw1ZHZTRER6ZUVqZUZrWkl2dDlpNWNW?=
 =?utf-8?B?NGxJekl4NW1rSC9iYjd4Wm53Tys2SmJNeEx4cVlmQzYyUU9SbDdJT0lYc0lM?=
 =?utf-8?B?RVRxTzhhWWZjMFB1S0VNZnQxcTVlYzZyRmQrM0pXaWxQYThKdW5iL0hzdjlH?=
 =?utf-8?B?N1JHWjVRSXI4bWp5ZFA0R2lwSlBha0xIa1V5T1NNVzQyeEFScXM0QTNyT3dX?=
 =?utf-8?B?ZU54UlNtaFAyU2xiQUJpcUVRMjdKSmlucU9Yb0txV2RlY0VwK1pRTHd2b2lT?=
 =?utf-8?B?MTlRT0luY0pvR3dqVkJxWVhTdlVjOG1nQmZGVytTU3BIYk8zeGZkVzFIU2x2?=
 =?utf-8?B?bzhKMllNV1lBVVBtL0duSkRsd2dxeGhOd2Q4UG93M2wxSWUvNkcxQTR0MTVD?=
 =?utf-8?B?alNkL1hRUHhBQXdpWlNObWVUbHlHMDBKZEFBeGtYN2gxRUtzdXdrSCtEZDZJ?=
 =?utf-8?B?a0pueUkzMjRkMVpmd2tiaSsvKzY5U21memIzRmJFSEFQRGVGbEJlbG80TEpJ?=
 =?utf-8?B?d0NJMXg1U20zK0hpRXZCYzY2TUxoZUUxRXNyR3h2eFgvakRKQ00xaGpDQ254?=
 =?utf-8?B?Z25EakJoVlBSRzJISy9ZeFIzaE0vN0lZb0pjM3QyRGhka29BaGNGNW1JcjFM?=
 =?utf-8?B?R25SSjd0ZFhtdUlvQW8wUE52ZzF4T0ZhcGlKSzV4bGw1cVFRb09FNnpKMzYv?=
 =?utf-8?B?dkVpV2s0ZUY0OFg2ZlY0bUxYQTk1UFduWE5OWkZFOFVHRVgvTEM5ZCs2SnpV?=
 =?utf-8?B?Vks0S1dPYVcvYzEzSG1ZcWE2SVg2b1NPN3Jra0MyR3VGT2dHM3dhbEpGYkhL?=
 =?utf-8?B?T3dsUHhWd1JWT2VPR1hGY05YanZQVnUwYUJwUTVaNmZmeTZrTDkxY0Z5bGhq?=
 =?utf-8?B?ZXJxekZRVEhJYytuN2lkVThuS1ROL0FjaTlOSW93eGhpU3k4YXFXanpaTEtV?=
 =?utf-8?B?dzZaUzZVSlJPdzRDRkIyK1FlZUZHaDdFejRXckJweCtlcjlYZ0Z1ODZxMVVF?=
 =?utf-8?B?V2ErQ3Q0eDJGQ3RTMkpweHJqV3BiS0lmTWk5ZThZeTdLblJoUnFKQXgxbWk2?=
 =?utf-8?B?dEpUV1ZXajdlOEkrUFhJelNlVUJlVVcrWCttM0NhWWN3M2JQSExhakF3d2hN?=
 =?utf-8?B?SFMvTm9sTXFTR3BwWm5pQjdpbGxDTlhnSk9XUlNxSWlnTHQyTndCZWloaFdP?=
 =?utf-8?B?ZXQ2eGQ2dkxCY25kbit5UE9HZW5pSkpSSVY3bUFEelo2aG1HMHZTZzM2enJI?=
 =?utf-8?B?bGtDQU5NeVpUUjZyTnRBdHVyTEZhRjdxVHlQcWxibXFEWUJScjBhMFg5cDlq?=
 =?utf-8?B?L2dZdVdXOU1jcnBSZ2taaUNHSG1tUGlja3JSUXVFVUVybzlyckJWcWxUOVYy?=
 =?utf-8?B?MG52MjZTKy9pR0o5eE02UUJrbHR0RDJFLzhweE9sMmNyTy8xMXExQ3ZQQmNR?=
 =?utf-8?B?Nmo1M2JhdkU0MTk4SjJ3RzVPbUdmb3pkbml0WEh1QTYvN1owdnA5TXdUT2VW?=
 =?utf-8?Q?tWI/DmISyWR0KxOX78mL?=
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e9212af8-ae27-4481-99e9-08dc8975ee0c
X-MS-Exchange-CrossTenant-AuthSource: CP8P284MB2148.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2024 17:51:18.0613
 (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: CP6P284MB1605
From: rodrigo.vieira92@outlook.com (Rodrigo Vieira)

--66673d11_4d64ce3a_3324
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I didn't like the =60Prefix-style=60 syntax. I prefer the =60Hook-embedde=
d-style=60 syntax. =46irst let's look at the counterpoints of the =60Pref=
ix-style=60 syntax:

=23=23 1) =22=60Prefix-style=60 is more visually scannable=22
> The set visibility is 10 lines away from the get visibility=21

Solution:
=60=60=60php
class HookEmbeddedStyle
=7B
=C2=A0=C2=A0 =C2=A0public string =24phone =7B
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0private set =7B
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=24this->phone =3D implode=
('', array=5Ffilter(fn(=24c) =3D> is=5Fnumeric(=24c), explode(=24value)))=

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=7D
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0get =7B
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (=21=24this->phone) =7B=

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return '';
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=7D
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (=24this->phone=5B0=5D =
=3D=3D=3D 1) =7B
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 'US '=
 . =24this->phone;
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=7D
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 'Intl +' . =24this-=
>phone;
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=7D
=C2=A0=C2=A0 =C2=A0=7D
=7D
=60=60=60
The set visibility is not 10 lines away from the get visibility if you pu=
t it at the top. =46or me this is about code convention, not about syntac=
tic structure:
only put the hook with explicit visibility at the top, when some of the h=
ooks do not have explicit visibility=21

=23=23 2) =22=60Prefix-style=60 is shorter=22
=60=60=60php
public private(set) string =24name;

public string =24name =7B private set; =7D
=60=60=60

Irrelevant to consider 1-2 characters.
If you break the lines needed for the hook block, the line (the horizonta=
l size) is smaller when using =60Hook-embedded-style=60 and in my opinion=
 it is more readable because there is less information per line:
=60=60=60php
public private(set) string =24name;

public string =24name =7B
=C2=A0 =C2=A0private set;
=7D
=60=60=60

=23=23 3) =22=60Prefix-style=60 doesn't presume a connection with hooks=22=

> As noted above in =22Interaction with hooks=22, visibility controls exi=
st independently of hooks.

I agree, but with Property Hooks, this should now define the overall visi=
bility only. Like a bigger gate that you open, and there are other doors =
defining the visibility of the operations get, set (hooks).

> In fact, as implemented, they don't interact at all. Using hook syntax =
for visibility controls is therefore surprising and confusing.

Why =22surprising and confusing=22=3F I see hooks as a different kind of =
function/method.
Property Hooks R=46C shouldn't pass without requiring hook parentheses, f=
or any hook when the property is not abstract. The =60=24value=60 in the =
=60set=60 hook seems to come out of nowhere to some people (the exception=
 is for hooks declared on an abstract property which you can define witho=
ut parameters and thus you are free to define whatever parameters you wan=
t on the concrete property).

When you define a method in PHP, it should be possible to omit the =22fun=
ction=22, but the parameters should be required because that's the nature=
 of a function/method: to have parameters.

=23=23 4) =22It's non-obvious in =60Hook-embedded-style=60 what hook beha=
vior should be implied=22

> ...So =E2=80=9Carrays with hooks can do less=E2=80=9D is already an est=
ablished fact of the language. However, if the hook-style syntax is used =
for visibility:

=60=60=60php
class A
=7B
=C2=A0=C2=A0 =C2=A0public array =24arr =7B protected set; =7D
=7D

class B extends A
=7B
=C2=A0=C2=A0 =C2=A0public function add(int =24val)
=C2=A0=C2=A0 =C2=A0=7B
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0// Should this be legal=3F
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=24this->arr=5B=5D =3D =24val;
=C2=A0=C2=A0 =C2=A0=7D
=7D

=24b =3D new B();

=24b->add(5);
=60=60=60
=46irst of all: non-abstract property hook must have a body.
Second: when asymmetric visibility is explicit, it means that symmetric v=
isibility is implicit: a declared hook that does not have declared visibi=
lity has the same general visibility as the property, in this case: publi=
c.

Third:
There's another limitation on hooks here that makes things a bit confusin=
g: there's a missing hook for a specific operation because you can clearl=
y separate the =60set=60 from the =60push=60 operation...

Solution:
=60=60=60php
abstract class A
=7B
=C2=A0=C2=A0 =C2=A0abstract public array =24arr =7B
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0push; // Hook available only for =22arra=
y=22 type properties only; public visibility
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0private set;
=C2=A0=C2=A0 =C2=A0=7D
=7D

class B extends A
=7B
=C2=A0=C2=A0 =C2=A0public array =24arr =7B
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0push (=24value) =7B // =60public push ..=
.=60 here is redundant
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Mandatory to implement =
logic here.
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=7D
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0private set (=24value) =7B
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Mandatory to Implement =
logic here.
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=7D
=C2=A0=C2=A0 =C2=A0=7D

=C2=A0=C2=A0 =C2=A0public function =5F=5Fconstruct ()
=C2=A0=C2=A0 =C2=A0=7B
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0// Legal =E2=9C=85 (set hook is protecte=
d)
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=24this->arr =3D =5B1=5D; // call set ho=
ok
=C2=A0=C2=A0 =C2=A0=7D
=C2=A0=C2=A0 =C2=A0public function add(int =24value)
=C2=A0=C2=A0 =C2=A0=7B
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0// Legal =E2=9C=85 (push hook is public)=

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=24this->arr=5B=5D =3D =24value; // call=
 push hook
=C2=A0=C2=A0 =C2=A0=7D
=7D

=24b =3D new B();

=24b->add(5);
=24b->arr; // Legal =E2=9C=85 (Inherited from the general visibility that=
 is public)
=24b->arr =3D =5B1, 2, 3=5D; // =46atal error =E2=9D=8C - access to set h=
ook is private only
=24b->arr=5B=5D =3D 4; // Legal =E2=9C=85 - call public push hook
=60=60=60

My point: =60Prefix-style=60 is not future-proof
=23=23 1) The =60Prefix-style=60 is not compatible with new hooks
If more hooks are added in the future, such as the =60push=60 hook for ar=
rays or even a hook that is compatible with all types such as =60init=60,=
 =60Hook-embedded-style=60 will become compatible, but =60Prefix-style=60=
 not.

=23=23 2) Hook overloading
If hook overloading is added in the future, =60Prefix-style=60 would not =
be supported to have this granular visibility into operations. =46or exam=
ple, it might be possible to add a public hook and a protected hook for t=
he same operation, where one would be triggered if the operation occurred=
 from outside the class, and the other if the operation occurred from ins=
ide the class.
Em 10 de jun. de 2024 13:15 -0300, Tiffany <tiffany.k.taylor=40gmail.com>=
 escreveu:
>
> > On Wed, May 29, 2024, 2:16=E2=80=AFPM Larry Garfield <larry=40garfiel=
dtech.com> wrote:
> > > As promised, Ilija and I offer this revised version of asymmetric v=
isibility.
> > >
> > > https://wiki.php.net/rfc/asymmetric-visibility-v2
> > >
> > > It's still essentially the same as last year's version, but with a =
few adjustments and changes:
> > >
> > > * readonly properties are now supported in a logical fashion.
> > > * We've brought back the abbreviated form, as public-read, somethin=
g else set is the most common use case.
> > > * The section on magic methods has been greatly simplified.=C2=A0 T=
he implementation itself hasn't changed, but the explanation is a lot les=
s 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 exist =
at the time of the last draft.
> > > * We've added a section with examples of how aviz is a concrete imp=
rovement, even in a world with readonly and hooks.
> > > * We've added a section discussing why the prefix-style syntax was =
chosen.
> > >
> > > *dons flame retardant suit*
> > >
> > > --
> > > =C2=A0 Larry Garfield
> > > =C2=A0 larry=40garfieldtech.com
>
> Sending an email to quickly enable a new mailing list subscriber to eng=
age in the conversation.

--66673d11_4d64ce3a_3324
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">I didn't like the `Prefix-style` syntax. I prefer the `Ho=
ok-embedded-style` syntax. First let's look at the counterpoints of the `Pr=
efix-style` syntax:<br>
<br>
## 1) &quot;`Prefix-style` is more visually scannable&quot;<br>
&gt; The set visibility is 10 lines away from the get visibility!<br>
<br>
Solution:<br>
```php<br>
class HookEmbeddedStyle<br>
{<br>
&nbsp;&nbsp; &nbsp;public string $phone {<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;private set {<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;$this-&gt;phone =3D implode(=
'', array_filter(fn($c) =3D&gt; is_numeric($c), explode($value)))<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;}<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;get {<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if (!$this-&gt;phone) {<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return '';<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if ($this-&gt;phone[0] =3D=
=3D=3D 1) {<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return 'US ' .=
 $this-&gt;phone;<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return 'Intl +' . $this-&gt;=
phone;<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;}<br>
&nbsp;&nbsp; &nbsp;}<br>
}<br>
```<br>
The set visibility is not 10 lines away from the get visibility if you put =
it at the top. For me this is about code convention, not about syntactic st=
ructure:<br>
only put the hook with explicit visibility at the top, when some of the hoo=
ks do not have explicit visibility!<br>
<br>
## 2) &quot;`Prefix-style` is shorter&quot;<br>
```php<br>
public private(set) string $name;<br>
<br>
public string $name { private set; }<br>
```<br>
<br>
Irrelevant to consider 1-2 characters.<br>
If you break the lines needed for the hook block, the line (the horizontal =
size) is smaller when using `Hook-embedded-style` and in my opinion it is m=
ore readable because there is less information per line:<br>
```php<br>
public private(set) string $name;<br>
<br>
public string $name {<br>
&nbsp; &nbsp;private set;<br>
}<br>
```<br>
<br>
## 3) &quot;`Prefix-style` doesn't presume a connection with hooks&quot;<br=
>
&gt; As noted above in &quot;Interaction with hooks&quot;, visibility contr=
ols exist independently of hooks.<br>
<br>
I agree, but with Property Hooks, this should now define the overall visibi=
lity only. Like a bigger gate that you open, and there are other doors defi=
ning the visibility of the operations get, set (hooks).<br>
<br>
&gt; In fact, as implemented, they don't interact at all. Using hook syntax=
 for visibility controls is therefore surprising and confusing.<br>
<br>
Why &quot;surprising and confusing&quot;? I see hooks as a different kind o=
f function/method.&nbsp;<br>
Property Hooks RFC shouldn't pass without requiring hook parentheses, for a=
ny hook when the property is not abstract. The `$value` in the `set` hook s=
eems to come out of nowhere to some people (the exception is for hooks decl=
ared on an abstract property which you can define without parameters and th=
us you are free to define whatever parameters you want on the concrete prop=
erty).<br>
<br>
When you define a method in PHP, it should be possible to omit the &quot;fu=
nction&quot;, but the parameters should be required because that's the natu=
re of a function/method: to have parameters.<br>
<br>
## 4) &quot;It's non-obvious in `Hook-embedded-style` what hook behavior sh=
ould be implied&quot;<br>
<br>
&gt; ...So =E2=80=9Carrays with hooks can do less=E2=80=9D is already an es=
tablished fact of the language. However, if the hook-style syntax is used f=
or visibility:<br>
<br>
```php<br>
class A<br>
{<br>
&nbsp;&nbsp; &nbsp;public array $arr { protected set; }<br>
}<br>
&nbsp;<br>
class B extends A<br>
{<br>
&nbsp;&nbsp; &nbsp;public function add(int $val)<br>
&nbsp;&nbsp; &nbsp;{<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;// Should this be legal?<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;$this-&gt;arr[] =3D $val;<br>
&nbsp;&nbsp; &nbsp;}<br>
}<br>
&nbsp;<br>
$b =3D new B();<br>
&nbsp;<br>
$b-&gt;add(5);<br>
```<br>
First of all: non-abstract property hook must have a body.<br>
Second: when asymmetric visibility is explicit, it means that symmetric vis=
ibility is implicit: a declared hook that does not have declared visibility=
 has the same general visibility as the property, in this case: public.<br>
<br>
Third:<br>
There's another limitation on hooks here that makes things a bit confusing:=
 there's a missing hook for a specific operation because you can clearly se=
parate the `set` from the `push` operation...<br>
<br>
Solution:<br>
```php<br>
abstract class A<br>
{<br>
&nbsp;&nbsp; &nbsp;abstract public array $arr {<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;push; // Hook available only for &quot;arr=
ay&quot; type properties only; public visibility<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;private set;<br>
&nbsp;&nbsp; &nbsp;}<br>
}<br>
<br>
class B extends A<br>
{<br>
&nbsp;&nbsp; &nbsp;public array $arr {<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;push ($value) { // `public push ...` here =
is redundant<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// Mandatory to implement lo=
gic here.<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;}<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;private set ($value) {<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// Mandatory to Implement lo=
gic here.<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;}<br>
&nbsp;&nbsp; &nbsp;}<br>
<br>
&nbsp;&nbsp; &nbsp;public function __construct ()<br>
&nbsp;&nbsp; &nbsp;{<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;// Legal =E2=9C=85 (set hook is protected)=
<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;$this-&gt;arr =3D [1]; // call set hook<br=
>
&nbsp;&nbsp; &nbsp;}<br>
&nbsp;&nbsp; &nbsp;public function add(int $value)<br>
&nbsp;&nbsp; &nbsp;{<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;// Legal =E2=9C=85 (push hook is public)<b=
r>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;$this-&gt;arr[] =3D $value; // call push h=
ook<br>
&nbsp;&nbsp; &nbsp;}<br>
}<br>
<br>
$b =3D new B();<br>
<br>
$b-&gt;add(5);<br>
$b-&gt;arr; // Legal =E2=9C=85 (Inherited from the general visibility that =
is public)&nbsp;<br>
$b-&gt;arr =3D [1, 2, 3]; // Fatal error =E2=9D=8C - access to set hook is =
private only<br>
$b-&gt;arr[] =3D 4; // Legal =E2=9C=85 - call public push hook<br>
```<br>
<br>
My point: `Prefix-style` is not future-proof<br>
## 1) The `Prefix-style` is not compatible with new hooks<br>
If more hooks are added in the future, such as the `push` hook for arrays o=
r even a hook that is compatible with all types such as `init`, `Hook-embed=
ded-style` will become compatible, but `Prefix-style` not.<br>
<br>
## 2) Hook overloading<br>
If hook overloading is added in the future, `Prefix-style` would not be sup=
ported to have this granular visibility into operations. For example, it mi=
ght be possible to add a public hook and a protected hook for the same oper=
ation, where one would be triggered if the operation occurred from outside =
the class, and the other if the operation occurred from inside the class.</=
div>
</div>
<div name=3D"messageReplySection">Em 10 de jun. de 2024 13:15 -0300, Tiffan=
y &lt;tiffany.k.taylor@gmail.com&gt; escreveu:<br>
<blockquote type=3D"cite">
<div dir=3D"auto">
<div><br>
<div class=3D"gmail_quote">
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, May 29, 2024, 2:16=E2=80=AFPM=
 Larry Garfield &lt;<a href=3D"mailto:larry@garfieldtech.com">larry@garfiel=
dtech.com</a>&gt; wrote:<br></div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">As promised, Ilija and I offer this revised =
version of asymmetric visibility.&nbsp;<br>
<br>
<a href=3D"https://wiki.php.net/rfc/asymmetric-visibility-v2" rel=3D"norefe=
rrer noreferrer" target=3D"_blank">https://wiki.php.net/rfc/asymmetric-visi=
bility-v2</a><br>
<br>
It's still essentially the same as last year's version, but with a few adju=
stments 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 else s=
et is the most common use case.<br>
* The section on magic methods has been greatly simplified.&nbsp; The imple=
mentation itself hasn't changed, but the explanation is a lot less confusin=
g now.<br>
* We've explained how aviz interacts with hooks (they don't, really) and wi=
th interface properties (in the obvious way), which didn't exist at the tim=
e of the last draft.<br>
* We've added a section with examples of how aviz is a concrete improvement=
, even in a world with readonly and hooks.<br>
* We've added a section discussing why the prefix-style syntax was chosen.<=
br>
<br>
*dons flame retardant suit*<br>
<br>
--<br>
&nbsp; Larry Garfield<br>
&nbsp; <a href=3D"mailto:larry@garfieldtech.com" target=3D"_blank" rel=3D"n=
oreferrer">larry@garfieldtech.com</a></blockquote>
</div>
</div>
<div dir=3D"auto"><br></div>
<div dir=3D"auto">Sending an email to quickly enable a new mailing list sub=
scriber to engage in the conversation.</div>
</div>
</blockquote>
</div>
</body>
</html>

--66673d11_4d64ce3a_3324--