Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125431
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 04 Sep 2024 23:41:04 +0200
To: "John Bafford" <jbafford@zort.net>
Cc: internals@lists.php.net
Message-ID: <94510a5e-ae23-4118-ac55-2e90c911e7da@app.fastmail.com>
In-Reply-To: <7A98532B-7465-4FC5-B7A9-993E7D430EE1@zort.net>
References: 
 <CAPbW5OMLM=0k_WkL1K556O3+cq06X3iQ7OwgPWyjcUzBJ7opRA@mail.gmail.com>
 <27c3909f-05f4-4256-a447-10e8d8760fff@app.fastmail.com>
 <F9C739E2-2FA3-4CAF-9A9B-CE343F84B461@zort.net>
 <420bb5cb-5fca-4f2e-8c68-0ca327cd3392@app.fastmail.com>
 <7A98532B-7465-4FC5-B7A9-993E7D430EE1@zort.net>
Subject: Re: [PHP-DEV] Local constants
Content-Type: multipart/alternative;
 boundary=c0f6e3fbc97d4729865b8dbbc1dd8a2a
From: rob@bottled.codes ("Rob Landers")

--c0f6e3fbc97d4729865b8dbbc1dd8a2a
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Wed, Sep 4, 2024, at 23:11, John Bafford wrote:
>=20
> > On Sep 4, 2024, at 16:45, Rob Landers <rob@bottled.codes> wrote:
> >=20
> > I think, conceptually, this makes sense, but maybe I'm the only one =
who writes
> >=20
> > $arr =3D doSomething();
> > $arr =3D array_map(fn($x) =3D> $x->prop, $arr);
> > $arr =3D array_filter($arr, $filterFunc);
> >=20
> > instead of
> >=20
> > $arr =3D array_filter(array_map(fn($x) =3D> $x->prop, doSomething())=
, $filterFunc);
>=20
> IMO, that's a failing of PHP not supporting object syntax (and reasona=
ble api) for non-object values. In other languages, I can write code suc=
h as:
>=20
> let arr =3D doSomething()
>     .map { $0.prop }
>     .filter(filterFunc)
>=20
> Which is more readable than both PHP versions.

I think that sidesteps the reality we are currently in and is orthogonal=
 to the actual problem I perceive. To be more clear, I think with the cu=
rrent APIs in PHP, having local constants would incentivize people to wr=
ite less readable code for the reasons you mentioned. Could the APIs be =
improved? Probably, if not certainly, but that is not what is on the tab=
le.=20

>=20
> > And I feel like having constant variables would result in more of th=
e latter, which I feel is more unreadable. Though I do note that my opin=
ion of what is readable might be different from other people's.
> >=20
> > That being said, I would much rather see block-scoped variables than=
 local variables via let or var or something:
> >=20
> > var $aNumber =3D 12;
> >=20
> > foreach($arr as var $item) {
> >   echo $item; // item exists here
> > }
> >=20
> > echo $item; // item doesn't exist here
> >=20
> > PHP is simply too verbose to really benefit from local constants, bu=
t would benefit from block-scope far more. For example, with local const=
ants, you couldn't write that foreach because that variable exists in th=
e scope of the function and can only be defined once.
> >=20
> > =E2=80=94 Rob
>=20
> I'd suggest that the foreach could be written with either of let/var t=
o both locally scope $item, which would explicitly disallow/allow $item =
to be changed while in the loop.

Maybe, but I only mention that block-scope would be more valuable than l=
ocal constants. That they work well together is also interesting.

>=20
> Another benefit of local constants is preventing accidentally reusing =
a prior variable. For example, if I set a temporary variable to somethin=
g, and then later in the function, reuse that same name for a new tempor=
ary but don't set the value on all flow paths, then the value from earli=
er in the function leaks through, whereas either using a constant, or a =
second explicit variable definition would have exposed and/or prevented =
the issue.
>=20
> -John

This is a problem that I have run into in only a handful of times in my =
entire career, across all languages, lots of times in JavaScript files o=
f yesteryear when we had to deal with 10k loc handrolled files. I=E2=80=99=
ve seen this happen maybe 2-3 times in php (where it has been a bug), an=
d a couple of times in C. I don=E2=80=99t think I=E2=80=99ve ever run in=
to it in C#, Scala, or Python. Maybe I=E2=80=99m just lucky, but I don=E2=
=80=99t feel like this is a valid reason for the feature.

Const was added to JavaScript (according to my cobwebbed memories) to in=
troduce block scoping and optimizations around that. In PHP, we also hav=
e function scope, like JavaScript, but we also have lexical scope as wel=
l. Javascript did not have that at the time; in other words, the followi=
ng would have output "world":

function test() {
  console.log(hello)
  var hello =3D 'world'
}

test();

Today, it doesn't, and neither would php. The problems that const/let se=
t out to solve in Javascript do not apply here, IMHO.

=E2=80=94 Rob
--c0f6e3fbc97d4729865b8dbbc1dd8a2a
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}=0Ap.MsoNormal,p.MsoNoSpacing{margin:0}</=
style></head><body><div><br></div><div><br></div><div>On Wed, Sep 4, 202=
4, at 23:11, John Bafford wrote:<br></div><blockquote type=3D"cite" id=3D=
"qt" style=3D""><div><br></div><div>&gt; On Sep 4, 2024, at 16:45, Rob L=
anders &lt;<a href=3D"mailto:rob@bottled.codes">rob@bottled.codes</a>&gt=
; wrote:<br></div><div>&gt;&nbsp;<br></div><div>&gt; I think, conceptual=
ly, this makes sense, but maybe I'm the only one who writes<br></div><di=
v>&gt;&nbsp;<br></div><div>&gt; $arr =3D doSomething();<br></div><div>&g=
t; $arr =3D array_map(fn($x) =3D&gt; $x-&gt;prop, $arr);<br></div><div>&=
gt; $arr =3D array_filter($arr, $filterFunc);<br></div><div>&gt;&nbsp;<b=
r></div><div>&gt; instead of<br></div><div>&gt;&nbsp;<br></div><div>&gt;=
 $arr =3D array_filter(array_map(fn($x) =3D&gt; $x-&gt;prop, doSomething=
()), $filterFunc);<br></div><div><br></div><div>IMO, that's a failing of=
 PHP not supporting object syntax (and reasonable api) for non-object va=
lues. In other languages, I can write code such as:<br></div><div><br></=
div><div>let arr =3D doSomething()<br></div><div>&nbsp;&nbsp;&nbsp; .map=
 { $0.prop }<br></div><div>&nbsp;&nbsp;&nbsp; .filter(filterFunc)<br></d=
iv><div><br></div><div>Which is more readable than both PHP versions.<br=
></div></blockquote><div><br></div><div>I think that sidesteps the reali=
ty we are currently in and is orthogonal to the actual problem I perceiv=
e. To be more clear, I think with the current APIs in PHP, having local =
constants would incentivize people to write less readable code for the r=
easons you mentioned. Could the APIs be improved? Probably, if not certa=
inly, but that is not what is on the table.&nbsp;<br></div><div><br></di=
v><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div>&gt=
; And I feel like having constant variables would result in more of the =
latter, which I feel is more unreadable. Though I do note that my opinio=
n of what is readable might be different from other people's.<br></div><=
div>&gt;&nbsp;<br></div><div>&gt; That being said, I would much rather s=
ee block-scoped variables than local variables via let or var or somethi=
ng:<br></div><div>&gt;&nbsp;<br></div><div>&gt; var $aNumber =3D 12;<br>=
</div><div>&gt;&nbsp;<br></div><div>&gt; foreach($arr as var $item) {<br=
></div><div>&gt;&nbsp;&nbsp; echo $item; // item exists here<br></div><d=
iv>&gt; }<br></div><div>&gt;&nbsp;<br></div><div>&gt; echo $item; // ite=
m doesn't exist here<br></div><div>&gt;&nbsp;<br></div><div>&gt; PHP is =
simply too verbose to really benefit from local constants, but would ben=
efit from block-scope far more. For example, with local constants, you c=
ouldn't write that foreach because that variable exists in the scope of =
the function and can only be defined once.<br></div><div>&gt;&nbsp;<br><=
/div><div>&gt; =E2=80=94 Rob<br></div><div><br></div><div>I'd suggest th=
at the foreach could be written with either of let/var to both locally s=
cope $item, which would explicitly disallow/allow $item to be changed wh=
ile in the loop.<br></div></blockquote><div><br></div><div>Maybe, but I =
only mention that block-scope would be more valuable than local constant=
s. That they work well together is also interesting.<br></div><div><br><=
/div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div>=
Another benefit of local constants is preventing accidentally reusing a =
prior variable. For example, if I set a temporary variable to something,=
 and then later in the function, reuse that same name for a new temporar=
y but don't set the value on all flow paths, then the value from earlier=
 in the function leaks through, whereas either using a constant, or a se=
cond explicit variable definition would have exposed and/or prevented th=
e issue.<br></div><div><br></div><div>-John<br></div></blockquote><div><=
br></div><div>This is a problem that I have run into in only a handful o=
f times in my entire career, across all languages, lots of times in Java=
Script files of yesteryear when we had to deal with 10k loc handrolled f=
iles. I=E2=80=99ve seen this happen maybe 2-3 times in php (where it has=
 been a bug), and a couple of times in C. I don=E2=80=99t think I=E2=80=99=
ve ever run into it in C#, Scala, or Python. Maybe I=E2=80=99m just luck=
y, but I don=E2=80=99t feel like this is a valid reason for the feature.=
<br></div><div><br></div><div>Const was added to JavaScript (according t=
o my cobwebbed memories) to introduce block scoping and optimizations ar=
ound that. In PHP, we also have function scope, like JavaScript, but we =
also have lexical scope as well. Javascript did not have that at the tim=
e; in other words, the following would have output "world":<br></div><di=
v><br></div><div>function test() {<br></div><div>&nbsp; console.log(hell=
o)<br></div><div>&nbsp; var hello =3D 'world'<br></div><div>}<br></div><=
div><br></div><div>test();<br></div><div><br></div><div>Today, it doesn'=
t, and neither would php. The problems that const/let set out to solve i=
n Javascript do not apply here, IMHO.</div><div><br></div><div id=3D"sig=
121229152">=E2=80=94 Rob<br></div></body></html>
--c0f6e3fbc97d4729865b8dbbc1dd8a2a--