Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125447
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\))
Subject: Re: [PHP-DEV] Local constants
In-Reply-To: <ED7A6AE0-75FF-4765-BF46-F0A3206473D5@rwec.co.uk>
Date: Thu, 5 Sep 2024 22:01:46 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <9045A1B9-2880-4FB4-88F4-1AF7EBF0F3E0@newclarity.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>
 <94510a5e-ae23-4118-ac55-2e90c911e7da@app.fastmail.com>
 <77C2D2CC-5E1E-40D9-9FB3-A5C4A6311669@newclarity.net>
 <ED7A6AE0-75FF-4765-BF46-F0A3206473D5@rwec.co.uk>
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
From: mike@newclarity.net (Mike Schinkel)

On Sep 5, 2024 at 5:46 PM, <Rowan Tommins [IMSoP]> wrote:

> Block-scoping doesn't have to allow shadowing of names,=20

How exactly would that work?  Are you suggesting to restrict the use of =
variable names to one per function but still allow for block scoping?

Or if not, how would an inner block variable $x not shadow an outer =
variable $x? Shadowing is not a feature that is added, it is the result =
of block scoping, AFAIK.

> and it certainly doesn't have to be achieved by that incredibly hard =
to spot syntax. In most languages I've seen, it's indicated by either a =
keyword such as "let", "var", or "my"; or by  indicating the type of the =
variable you're declaring.

That declaration syntax is not what makes it problematic, it is the =
number of lines between the two declarations. I would not be so against =
it if most people kept their functions to 25 lines or less, but what =
have I have seen to think 200 to 500 line functions are the norm in =
legacy code I've had to work on.

But then if most people kept their functions small there would be far =
less "need" for block scoping. (Actually =E2=80=94 to channel Rob =E2=80=94=
 block scoping could encourage people to wrote longer functions which =
would definitely be a negative outcome.)

> For one thing, it would make me much more likely to accept the =
repeated requests for closures which capture parent scope by default, =
because it would give a clear opt-out to replace the current clear =
opt-in of the use() clause.

Scoping within a closure differs from in-line blocks having their own =
scope. For one, a closure is separated by a parameter stack whereas a =
block shares the stack with its function. Closures can be assigned to =
variables and objects properties and also passed to functions, blocks =
cannot. Closures have their own return values, blocks have no return =
statements thus are coupled to the function's scope. And finally and =
most importantly, the point of a closure is to delay or delegate =
execution whereas blocks execute inline with the function where they are =
located. For all these reasons local scope makes sense in closures =
whereas IMO scope in blocks does not.

> It's something I'd really like to see in PHP.=20

Be careful what you wish for. But don't say I did not warn you if it =
comes to pass.

> I've never found myself wishing for local constants, but never really =
used a language with them, so maybe I'd find them valuable if they were =
added.

Ignorance is bliss. And I mean that literally, not pejoratively.

> For completeness, I'll mention that *typed* local variables are =
another related concept, which has also come up in the past.

You'll get no argument from me on type local vars.

> The big challenge in all of them is that these are big fundamental =
language changes, which require an expert knowledge of how the language =
works under the hood=20

Really? I believe what the OP was asking for =E2=80=94 or at least it is =
what I would be interested in =E2=80=94 are immutable variables that we =
could conveniently declare with `const`. I could be wrong but it seems =
the only thing it would require is the compiler to throw an error when =
asked to generate a variable assignment opcode to any variable declared =
as a const.

The above assumes piggybacking on variables with `$` syntax vs. no-`$` =
syntax, so maybe using `const` would not be the best keyword. We could =
use `var` but that doesn't indicate immutability. =20

Or it may possible that implementing as `const` w/o `$` syntax would not =
be hard given that global const names are already recognized by the =
parser. And they could internally be kept on the same stack as =
variables.

> Let's not get too deep into discussing the colour of the bikeshed =
before we've worked out if there's space to build one.

It is ironic you say we should make sure it's possible before we discuss =
if we want it. I know I have heard the opposite many times on this list =
=E2=80=94 make sure we even want it before we worry about how to =
implement =E2=80=94 although I cannot say for sure that it was ever you =
that said that.

Whatever the case, of the features that have been implemented in recent =
years I find it hard to believe adding local constants would be nearly =
as hard as some of those features. Certainly easier than aviz.

-Mike=