Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125458
Content-Type: text/plain;
	charset=us-ascii
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: <5d6f5a8b-05c3-4519-b5e0-1c8c51b9d626@app.fastmail.com>
Date: Fri, 6 Sep 2024 15:42:22 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <C76B2495-ECC6-4A5F-9B1F-2CC6E9064325@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>
 <9045A1B9-2880-4FB4-88F4-1AF7EBF0F3E0@newclarity.net>
 <5d6f5a8b-05c3-4519-b5e0-1c8c51b9d626@app.fastmail.com>
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
From: mike@newclarity.net (Mike Schinkel)

> On Sep 6, 2024, at 4:47 AM, Rowan Tommins [IMSoP] =
<imsop.php@rwec.co.uk> wrote:
>=20
> On Fri, 6 Sep 2024, at 03:01, Mike Schinkel wrote:
>>> Block-scoping doesn't have to allow shadowing of names,=20
>>=20
>> How exactly would that work?  Are you suggesting to restrict the use =
of=20
>> variable names to one per function but still allow for block scoping?
>=20
> Yes. That's how C# works, for example - variables are scoped to the =
block where they're declared, but each name declared must be unique, not =
shadowing one that's currently in scope.

Interesting. That seems... an odd choice, just to enable block scoping. =20=


BTW, I find block scoping has more pain than pleasure, even when it is =
not exactly causing bugs, e.g.:

if (is_null($widget =3D getWidget())) {
   return;
}
echo $widget->name;  //  block-scoped $widget not available

The above would actually be a runtime bug in PHP, if the code were not =
covered by testing beforehand. In a statically-typed pre-compiled =
language like Go, it is just an annoyance.

OTOH, I very rarely ever find a situation where I am actually happy to =
have block scoping. IOW, I don't know what it enables that make people =
want it so badly, except possibly conflating closures with =
scoped-blocks, or ability to further control scoping in (too) long =
functions.

I think features that would reward people for writing shorter functions =
would be much better, but maybe that is just me.


>> Shadowing is not a feature that is added, it is the result=20
>> of block scoping, AFAIK.
>=20
> Shadowing is absolutely a feature that has to be implemented: the =
compiler has to store some "backup" of the old name binding, so that it =
can be "restored" when the shadowing variable goes out of scope. Without =
shadowing, it's instead about tracking the "lifetime" of the variable, =
and refusing references to it outside of the block where it's "live". =
I'm sure the implementation of both versions varies wildly.

Meh, you can twist words to mean that, but your words ignore that all =
variable scoping is then explicitly implemented as feature.=20

What I meant was the language already implements variable scoping so =
there is no additional work needed beyond what they language already =
implements. Unless the language was weirdly designed in such a way that =
it cannot reuse existing scoping mechanisms, which I will admit may =
actually be true of PHP.

OTOH, I am not speaking of what you just revealed about C# which I find =
to be also be, weird.=20

> You're right, there is some value in letting people know that a =
feature would be popular if implemented. I'm just aware that threads =
like this can quickly grow into rambling discussions of wild ideas with =
little grounding in what's possible, or back-and-forth debates between =
two people about something completely hypothetical. When that happens, =
those with the experience to actually implement big new features tend to =
tune out.=20

With respect, local constants and/or immutable local variables are =
hardly "wild ideas," nor likely something that has "little grounding in =
what's possible."

-Mike=