Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125112
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 23 Aug 2024 11:13:39 +0200
To: internals@lists.php.net
Message-ID: <d26516d7-afaa-4174-81f0-361785908967@app.fastmail.com>
In-Reply-To: <a0db04a7fa1d9c77b9d2b0110b50a47ef959e98f.camel@ageofdream.com>
References: 
 <CAPyj-LCoBY2bPHLmsyONYDbY9aRSraLz5QNskeTiWfpMD0pTSg@mail.gmail.com>
 <c385b525-37f7-446b-aa96-72272ef9e407@app.fastmail.com>
 <CAPyj-LA4kTJTrQZUkn9kNMvWdH6SsFGU5mBO6EcpuUcRpXesgw@mail.gmail.com>
 <d4b18a48-93b0-49c8-821d-f9298e831188@rwec.co.uk>
 <BD6D644E-A90C-49B8-B51A-C9D4C943FDF6@newclarity.net>
 <846D7756-712B-4A7C-9FC6-DB9F858836B8@rwec.co.uk>
 <880ffc27dc9b421407a670c75d5f5ba756870396.camel@ageofdream.com>
 <790534cd-e158-4712-878c-642dfd0e2bad@app.fastmail.com>
 <a0db04a7fa1d9c77b9d2b0110b50a47ef959e98f.camel@ageofdream.com>
Subject: Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then
 local)
Content-Type: multipart/alternative;
 boundary=ccf354d2f16345278164b3e19537d691
From: rob@bottled.codes ("Rob Landers")

--ccf354d2f16345278164b3e19537d691
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 23, 2024, at 10:08, Nick Lockheart wrote:
>=20
> >=20
> > If we were to go with any major change in the current lookup where it
> > is perf or nothing, this is what I would propose for php 9.0
> > (starting with an immediate deprecation):
> >    1. any unqualified call simply calls the current namespace
> >    2. >=3D php 9.0: no fallback to global
> >    3. < php 9.0: emit deprecation notice if falls back to global
> > This is how classes work (pretty sure), so it would be consistent.
> >=20
> > Going the other way (global first) doesn't really make sense because
> > it is inconsistent, IMHO. Will it suck? Probably. Will it be easy to
> > fix? Probably via Rector.
> >=20
> > =E2=80=94 Rob
>=20
>=20
> A third option, which I haven't seen come up on the list yet, is that
> unqualified functions that are PHP built-ins are treated as global, and
> using a function having the same name as a built-in, in a namespace
> scope, requires a fully qualified name to override the built-in.
>=20
> It seems that if someone is writing `array_key_exists()` or similar
> they probably mean the built-in function, and in the rare cases where
> they do mean `\foo\array_key_exists()`, they can write it explicitly.
>=20
> Functions that are *not* on the built-in function list could default to
> the local namespace.

I was actually thinking of doing something like this for function autolo=
ading, where extensions could register global functions that bypass the =
autoloader and go straight to global if it isn't defined in the local na=
mespace already. I decided not to even bring it up because it felt contr=
oversial (it would effectively be global first, except for user function=
s). Though, it might be a nice compromise?

=E2=80=94 Rob
--ccf354d2f16345278164b3e19537d691
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}</style></head><body><div>On Fri, Aug 23,=
 2024, at 10:08, Nick Lockheart wrote:<br></div><blockquote type=3D"cite=
" id=3D"qt" style=3D""><div><br></div><div>&gt;&nbsp;<br></div><div>&gt;=
 If we were to go with any major change in the current lookup where it<b=
r></div><div>&gt; is perf or nothing, this is what I would propose for p=
hp 9.0<br></div><div>&gt; (starting with an immediate deprecation):<br><=
/div><div>&gt; &nbsp;&nbsp;&nbsp;1. any unqualified call simply calls th=
e current namespace<br></div><div>&gt; &nbsp;&nbsp;&nbsp;2. &gt;=3D php =
9.0: no fallback to global<br></div><div>&gt; &nbsp;&nbsp;&nbsp;3. &lt; =
php 9.0: emit deprecation notice if falls back to global<br></div><div>&=
gt; This is how classes work (pretty sure), so it would be consistent.<b=
r></div><div>&gt;&nbsp;<br></div><div>&gt; Going the other way (global f=
irst) doesn't really make sense because<br></div><div>&gt; it is inconsi=
stent, IMHO. Will it suck? Probably. Will it be easy to<br></div><div>&g=
t; fix? Probably via Rector.<br></div><div>&gt;&nbsp;<br></div><div>&gt;=
 =E2=80=94 Rob<br></div><div><br></div><div><br></div><div>A third optio=
n, which I haven't seen come up on the list yet, is that<br></div><div>u=
nqualified functions that are PHP built-ins are treated as global, and<b=
r></div><div>using a function having the same name as a built-in, in a n=
amespace<br></div><div>scope, requires a fully qualified name to overrid=
e the built-in.<br></div><div><br></div><div>It seems that if someone is=
 writing `array_key_exists()` or similar<br></div><div>they probably mea=
n the built-in function, and in the rare cases where<br></div><div>they =
do mean `\foo\array_key_exists()`, they can write it explicitly.<br></di=
v><div><br></div><div>Functions that are *not* on the built-in function =
list could default to<br></div><div>the local namespace.<br></div></bloc=
kquote><div><br></div><div>I was actually thinking of doing something li=
ke this for function autoloading, where extensions could register global=
 functions that bypass the autoloader and go straight to global if it is=
n't defined in the local namespace already. I decided not to even bring =
it up because it felt controversial (it would effectively be global firs=
t, except for user functions). Though, it might be a nice compromise?<br=
></div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></=
body></html>
--ccf354d2f16345278164b3e19537d691--