Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125448
Feedback-ID: id5114917:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 06 Sep 2024 09:47:07 +0100
To: internals@lists.php.net
Message-ID: <5d6f5a8b-05c3-4519-b5e0-1c8c51b9d626@app.fastmail.com>
In-Reply-To: <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>
 <9045A1B9-2880-4FB4-88F4-1AF7EBF0F3E0@newclarity.net>
Subject: Re: [PHP-DEV] Local constants
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On Fri, 6 Sep 2024, at 03:01, Mike Schinkel wrote:
>> Block-scoping doesn't have to allow shadowing of names,=20
>
> How exactly would that work?  Are you suggesting to restrict the use o=
f=20
> variable names to one per function but still allow for block scoping?

Yes. That's how C# works, for example - variables are scoped to the bloc=
k where they're declared, but each name declared must be unique, not sha=
dowing one that's currently in scope.


> Shadowing is not a feature that is added, it is the result=20
> of block scoping, AFAIK.

Shadowing is absolutely a feature that has to be implemented: the compil=
er 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 shado=
wing, it's instead about tracking the "lifetime" of the variable, and re=
fusing references to it outside of the block where it's "live". I'm sure=
 the implementation of both versions varies wildly.


> It is ironic you say we should make sure it's possible before we=20
> discuss if we want it. I know I have heard the opposite many times on=20
> this list =E2=80=94 make sure we even want it before we worry about ho=
w to=20
> implement =E2=80=94 although I cannot say for sure that it was ever yo=
u that=20
> said that.

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 c=
an quickly grow into rambling discussions of wild ideas with little grou=
nding in what's possible, or back-and-forth debates between two people a=
bout something completely hypothetical. When that happens, those with th=
e experience to actually implement big new features tend to tune out.=20

I will now try to practice what I preach, and not post further in this t=
hread unless it moves onto something more concrete.

Regards,
--=20
Rowan Tommins
[IMSoP]