Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125446
Feedback-ID: id5114917:Fastmail
Date: Thu, 05 Sep 2024 22:44:30 +0100
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Local constants
User-Agent: K-9 Mail for Android
In-Reply-To: <77C2D2CC-5E1E-40D9-9FB3-A5C4A6311669@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>
Message-ID: <ED7A6AE0-75FF-4765-BF46-F0A3206473D5@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 5 September 2024 16:53:32 BST, Mike Schinkel <mike@newclarity=2Enet> wr=
ote:
>
>Not convinced? At least one other person has my same view of the dark des=
pair of block-scoping:
>
>https://forum=2Egolangbridge=2Eorg/t/warning-for-accidental-variable-shad=
owing-with-block-scope/4715
>
>Of all the Go code I have written, I'd say accidental variable shadowing =
is in the top-three (3) reasons for bugs in my code, if not the main reason=
=2E And if it were not for BC breaks, I would lobby hard for Go to remove i=
t=2E I know that some on the Go team lament that they ever included it=2E

Block-scoping doesn't have to allow shadowing of names, and it certainly d=
oesn't have to be achieved by that incredibly hard to spot syntax=2E In mos=
t languages I've seen, it's indicated by either a keyword such as "let", "v=
ar", or "my"; or by  indicating the type of the variable you're declaring=
=2E

It's something I'd really like to see in PHP=2E For one thing, it would ma=
ke me much more likely to accept the repeated requests for closures which c=
apture parent scope by default, because it would give a clear opt-out to re=
place the current clear opt-in of the use() clause=2E

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=
=2E

For completeness, I'll mention that *typed* local variables are another re=
lated concept, which has also come up in the past=2E

The big challenge in all of them is that these are big fundamental languag=
e changes, which require an expert knowledge of how the language works unde=
r the hood to get much beyond "that would be nice to have"=2E Let's not get=
 too deep into discussing the colour of the bikeshed before we've worked ou=
t if there's space to build one=2E

Regards,
Rowan Tommins
[IMSoP]