Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119124
Message-ID: <84647C1B-0F61-41E5-981D-B860BE1E53CB@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_AD616805-7072-4EB6-AE2E-97B13C00FD5C"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Tue, 13 Dec 2022 16:34:56 +0100
In-Reply-To: <8f9cf24c-ee77-4227-9b7c-31c631bf8a72@app.fastmail.com>
Cc: php internals <internals@lists.php.net>
To: Larry Garfield <larry@garfieldtech.com>
References: <0854b030-c51c-4c1b-a7dd-22835a1e5da9@app.fastmail.com>
 <831b9906-dc0c-420c-b22f-8a0cc8a1ad64@app.fastmail.com>
 <454c5329-d5a3-5174-d09c-346b7d65435c@bastelstu.be>
 <8f9cf24c-ee77-4227-9b7c-31c631bf8a72@app.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
From: claude.pache@gmail.com (Claude Pache)

--Apple-Mail=_AD616805-7072-4EB6-AE2E-97B13C00FD5C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Le 11 d=C3=A9c. 2022 =C3=A0 20:18, Larry Garfield =
<larry@garfieldtech.com> a =C3=A9crit :
>=20
> On Thu, Dec 1, 2022, at 12:31 PM, Tim D=C3=BCsterhus wrote:
>> Hi
>>=20
>> On 11/29/22 21:29, Larry Garfield wrote:
>>> Thank you everyone for the feedback.  Based on this thread, we've =
made two changes to the RFC:
>>>=20
>>> 1. We've moved readonly back to forbidden with a-viz for now.  I've =
added a section to Future Scope where we really should sort this out in =
the future, but we'll do that in the future when we can all focus on the =
various nuances of just that piece.
>>>=20
>>> 2. I rewrote the section on __set to make it clearer.  That also =
included Ilija and I digging into all the nuances that are already =
present.  The text may still look a bit complex, but that's because the =
existing logic is already complex with readonly.  Long story short, the =
a-viz RFC does not change anything in the way __set works vis a vis =
asymmetric visibility; it just inherits and continues what readonly =
already started, so it's consistent.
>>>=20
>>> The PR should be updated in the next week or two with the latest =
changes.  Baring any major need for change, we expect to call a vote for =
it shortly after New Years.
>>>=20
>>=20
>> Okay, then I'd like to officially "request" that the abbreviated form=20=

>> [1] is dropped:
>>=20
>> I believe 'protected(set) string $foo' is easily confused with=20
>> 'protected string $foo' at a simple glance.
>>=20
>> Also any implicit rules are something developers will need to learn =
by=20
>> heart, whereas an explicit 'public protected(set) string $foo' could=20=

>> reasonably be understood by someone without any PHP experience and =
some=20
>> basic experience of OO concepts.
>>=20
>> Having two separate explicit keywords also makes it much clearer that=20=

>> asymmetric visibility is involved, because it's also asymmetric in =
the code.
>>=20
>> I believe the only benefit of the abbreviated form is saving 6=20
>> keystrokes (+ one hit to the spacebar) and I don't believe it's worth=20=

>> the lack of clarity for an important property of the defined =
property.
>>=20
>> Best regards
>> Tim D=C3=BCsterhus
>>=20
>> [1] https://wiki.php.net/rfc/asymmetric-visibility#abbreviated_form
>=20
>=20
> Does anyone else have feelings on this point?  IMO, the shorthand =
makes a lot of sense when used with readonly to avoid lines getting just =
annoyingly long, but without it I can see the argument for not allowing =
it; it's about a wash in terms of length with readonly today.  I'm =
comfortable going with the consensus on this one for now.
>=20
> --Larry Garfield

Hi,

As of today, the following declarations are rejected as syntax errors:

``php
class C {
    $a;
    int $b;
}
```

while the following declarations are accepted with implicit `public` =
visibility:

``php
class C {
    static $c;
    readonly int $d;
}
```

It would be reasonable to propose to allow to consistently omit the =
`public` keyword. But allowing to omit it in some cases (including the =
most controversial one: `protected(set)`) and not in other cases...? =
Because of this inconsistency, people are incited to always write =
explicitly `public` anyway.

=E2=80=94Claude



--Apple-Mail=_AD616805-7072-4EB6-AE2E-97B13C00FD5C--