Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123488
Precedence: bulk
MIME-Version: 1.0
References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com>
 <CAAwdEzB0rFhrai8W+B3PhnYEoOR-QEZYUm=R9+8+18Yo9WOgyQ@mail.gmail.com>
 <aadcd4ed-5f73-fbb9-93fb-42f2710e61fe@php.net> <ED20EE91-9BBB-4FED-8440-BAE748CBF5AB@gmail.com>
 <CAAwdEzBrRJMBQbY0R1Tp8RWpUP_DW6twNvGqnKDp3jjbiBFE-Q@mail.gmail.com> <734bb8e8-2fdf-4e50-9039-e53c99ee4930@app.fastmail.com>
In-Reply-To: <734bb8e8-2fdf-4e50-9039-e53c99ee4930@app.fastmail.com>
Date: Mon, 3 Jun 2024 10:54:07 +0300
Message-ID: <CAAwdEzA5KTROv8r3MtZ086T2Mcq+-1iGt=ZJkjzOL0ZLDuvqMw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004928e90619f7a472"
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--0000000000004928e90619f7a472
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 31, 2024 at 7:13=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com>
wrote:

>
> So we feel the best way forward is to make the following changes:
>
> * private(set) implicitly means "final".  (You can declare it explicitly
> if you want, but it isn't necessary.)
> * Make readonly incompatible with aviz again.
>
> Thoughts?
>

I think making properties `final` when using `private(set)` is a good
solution to this.

I don't think `readonly` needs to be incompatible with aviz. We can have
`readonly` act as `private(set`) but not `final` by default.
But you can define it as `private(set) readonly`, and in this case it will
be `final`, practically the same as `final readonly`.
It would go like this:
- private(set) -> final, private(set)
- final private(set) -> final, private(set)
- readonly -> write-once, private(set)
- final readonly -> final, write-once, private(set)
- private(set) readonly -> final, write-once, private(set)
- protected(set) readonly -> write-once, protected(set)
- public(set) readonly -> write-once, public(set)


>
> Also, Alexandru noted earlier that final properties don't seem to be
> supported in constructor promotion.  That's an oversight from the hooks
> implementation, not a design choice, so Ilija will just fix that as part =
of
> the hooks PR before it gets fully merged.
>

Maybe we need to have some discussion/considerations about allowing new
modifiers on constructor promoted properties parameters.
Right now there is no `final` modifier for parameters, but this means we
might not be able to allow them in the future.
In other languages (Java), it makes the parameter variable a constant (not
reassignable).

So this decision might have implications so that when we decide to make
variables or parameters not reassignable, we will not be able to use
"final" as a keyword.
Not saying there is a problem, just that we need to be aware of it, as
probably `final` is not a very good choice, and `const` or `readonly` are
probably better options.

Alex

--0000000000004928e90619f7a472
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Fri, May 31, 2024 at 7:13=E2=80=AFPM L=
arry Garfield &lt;<a href=3D"mailto:larry@garfieldtech.com">larry@garfieldt=
ech.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><br>
So we feel the best way forward is to make the following changes:<br>
<br>
* private(set) implicitly means &quot;final&quot;.=C2=A0 (You can declare i=
t explicitly if you want, but it isn&#39;t necessary.)<br>
* Make readonly incompatible with aviz again.<br>
<br>
Thoughts?<br></blockquote><div><br></div><div>I think making properties `fi=
nal` when using `private(set)` is a good solution to this.</div><div><br></=
div><div>I don&#39;t think `readonly` needs to be incompatible with aviz. W=
e can have `readonly` act as `private(set`) but not `final` by default.</di=
v><div>But you can define it as `private(set) readonly`, and in this case i=
t will be `final`, practically the same as `final readonly`.</div><div>It w=
ould go like this:</div><div>- private(set) -&gt; final, private(set)<br></=
div><div>- final private(set) -&gt; final, private(set)<br></div><div>- rea=
donly -&gt;=C2=A0write-once, private(set)</div><div>- final readonly -&gt; =
final, write-once, private(set)</div><div>- private(set) readonly -&gt; fin=
al, write-once, private(set)<br></div><div>- protected(set) readonly -&gt; =
write-once, protected(set)<br></div><div>- public(set) readonly -&gt; write=
-once, public(set)<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">
<br>
Also, Alexandru noted earlier that final properties don&#39;t seem to be su=
pported in constructor promotion.=C2=A0 That&#39;s an oversight from the ho=
oks implementation, not a design choice, so Ilija will just fix that as par=
t of the hooks PR before it gets fully merged.<br></blockquote><div><br></d=
iv><div>Maybe we need to have some discussion/considerations about allowing=
 new modifiers on constructor promoted properties parameters.<br>Right now =
there is no `final` modifier for parameters, but this means we might not be=
 able to allow=C2=A0them in the future.<br></div><div>In other languages (J=
ava), it makes the parameter variable a constant (not reassignable).</div><=
div><br></div><div>So this decision might have implications so that when we=
 decide to make variables or parameters not reassignable, we will not be ab=
le to use &quot;final&quot; as a keyword.</div><div>Not saying there is a p=
roblem, just that we need to be aware of it, as probably `final` is not a v=
ery good choice, and `const` or `readonly` are probably better options.</di=
v><div><br></div><div>Alex<br></div><div><br></div></div></div>

--0000000000004928e90619f7a472--