Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119108
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
In-Reply-To: <8f9cf24c-ee77-4227-9b7c-31c631bf8a72@app.fastmail.com>
Date: Mon, 12 Dec 2022 04:02:52 +0700
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <4A400B7F-45E3-45BF-98EF-475326147F5E@koalephant.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>
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
From: php-lists@koalephant.com (Stephen Reay)



> On 12 Dec 2022, at 02:18, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=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
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>=20

I=E2=80=99ll just re-iterate what I said in chat a while ago - I think =
requiring the dev to be explicit about making it public is a safer first =
step, and it has no BC risk if you wanted to later allow the implicit =
variant, and without the capability to combine with the readonly keyword =
(yet) it doesn=E2=80=99t seem like a huge problem to be explicit IMO.



Cheers

Stephen=20=