Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119229
MIME-Version: 1.0
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> <84647C1B-0F61-41E5-981D-B860BE1E53CB@gmail.com>
 <EB4F7DA5-A526-4E9C-ADF0-31DE86B7368F@gmail.com> <3d8561bd-fdb1-417a-836b-5146fca56185@app.fastmail.com>
 <845495d8-52da-4d2e-90ee-79c697d87f30@app.fastmail.com>
In-Reply-To: <845495d8-52da-4d2e-90ee-79c697d87f30@app.fastmail.com>
Date: Thu, 5 Jan 2023 15:53:50 +0100
Message-ID: <CAPzBOBMgdRU=pWg7A5+rz2tCO3KqB9TVWbOs6fXy4MG9+BqQ_g@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
From: landers.robert@gmail.com (Robert Landers)

One quick question,

Will changing the property of a protected/private set via reflection
be allowed? Or will you have to do some shenanigans like you currently
have to do with readonly?

Robert Landers
Software Engineer
Utrecht NL

On Wed, Jan 4, 2023 at 9:29 PM Larry Garfield <larry@garfieldtech.com> wrot=
e:
>
> On Wed, Dec 21, 2022, at 3:23 PM, Larry Garfield wrote:
> > On Tue, Dec 13, 2022, at 11:03 AM, Claude Pache wrote:
> >>> Le 13 d=C3=A9c. 2022 =C3=A0 16:34, Claude Pache <claude.pache@gmail.c=
om> a =C3=A9crit :
> >>>
> >>>
> >>> 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
> >>
> >>
> >> However, I=E2=80=99m just realising that omitting `public` in declarat=
ions like
> >> `public $a` and `public int $b` is probably not a good idea, because i=
t
> >> is incompatible with constructor property promotion, as `function
> >> __construct(public int $b) { }`, and `function __construct(int $b) { }=
`
> >> have different meanings.
> >>
> >> =E2=80=94Claude
> >
> > Well, it seems the only people who have opinions on the abbreviated
> > form at all dislike it, so we've removed it for now and left a mention
> > in future-scope.  A future RFC can add that if desired.
> >
> > That should, I think, be the final change to the asymmetric visibility
> > RFC.  Baring anything else coming up, I expect to call the vote
> > sometime the week of 2 January.
> >
> > Happy $holiday!
> >
> > --Larry Garfield
>
> Happy New Year, PHP.  Fair warning, I will be opening the vote for asymme=
tric visibility on Friday, baring any sudden new inputs in the next 40-ish =
hours.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>