Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125066
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 20 Aug 2024 11:01:34 +0200
To: internals@lists.php.net
Message-ID: <fab5cbec-2a6c-4f00-8816-bd4579a3a6bb@app.fastmail.com>
In-Reply-To: <095f08ad4406a2166b3c5ddf472959daceef6502.camel@ageofdream.com>
References: 
 <CAPyj-LCoBY2bPHLmsyONYDbY9aRSraLz5QNskeTiWfpMD0pTSg@mail.gmail.com>
 <c385b525-37f7-446b-aa96-72272ef9e407@app.fastmail.com>
 <CAPyj-LA4kTJTrQZUkn9kNMvWdH6SsFGU5mBO6EcpuUcRpXesgw@mail.gmail.com>
 <CAAwdEzDqcCa-rQMFmD+6mQ4wWHJW+8Bi4_5LQ3GbfcK4PCYp3Q@mail.gmail.com>
 <095f08ad4406a2166b3c5ddf472959daceef6502.camel@ageofdream.com>
Subject: Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then
 local)
Content-Type: multipart/alternative;
 boundary=ef75ea3718744f47819394c53f15de77
From: rob@bottled.codes ("Rob Landers")

--ef75ea3718744f47819394c53f15de77
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Tue, Aug 20, 2024, at 10:41, Nick Lockheart wrote:
>=20
> > We would upgrade that to a warning in PHP 9.2, and it would end up
> > being an error on PHP 10 and have a BC break.
> >=20
> > I don't think adding a \ to each function call is ugly, that's what
> > we have for classes, and it works fine; or an use statement.
> >=20
> > So, why do we think that after people get used to it, they would
> > still consider it ugly? Never heard the "ugliness" mentioned for
> > classes.
>=20
>=20
> Respectfully, I think `\` is ugly for both functions and classes.
>=20
>=20
> > Now, I know this would be a big BC break, but it brings consistency
> > to the language and forces everyone to improve their code
> > performance.
>=20
> There should be a directive for this, like:
>=20
>     namespace foo using global functions;
>=20
> ...which automatically acts as if all functions have a \ in front of
> them, unless they are fully qualified.
>=20

Respectfully, I feel like this gets into the heart of a problem with RFC=
s, where if someone wants to implement something, they have to solve eve=
ryone=E2=80=99s problems.

In this case, there is a problem with performance issues due to multiple=
 lookups (though, I=E2=80=99m not convinced fully), so if someone wants =
to implement function autoloading, they also have to solve this problem =
(Gina and I have both independently solved it in various ways).

Personally, I=E2=80=99m of the opinion that if you want performance, you=
 know what to do: fully qualify your names. If you don=E2=80=99t care (w=
hich is what I gather from the first email in this thread where maintain=
ers were not willing to change their code), then =E2=80=9Cdeal with it.=E2=
=80=9D

The vast majority of performance issues won=E2=80=99t be caused by funct=
ion lookups, but by databases and poorly written code. Maybe I am wrong,=
 but I rather like what we currently have, whatever benchmarks have to s=
ay on the matter.=20

=E2=80=94 Rob
--ef75ea3718744f47819394c53f15de77
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><br></div><div>=
<br></div><div>On Tue, Aug 20, 2024, at 10:41, Nick Lockheart wrote:<br>=
</div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div=
>&gt; We would upgrade that to a warning in PHP 9.2, and it would end up=
<br></div><div>&gt; being an error on PHP 10 and have a BC break.<br></d=
iv><div>&gt;&nbsp;<br></div><div>&gt; I don't think adding a \ to each f=
unction call is ugly, that's what<br></div><div>&gt; we have for classes=
, and it works fine; or an use statement.<br></div><div>&gt;&nbsp;<br></=
div><div>&gt; So, why do we think that after people get used to it,&nbsp=
;they would<br></div><div>&gt; still consider it ugly? Never heard the "=
ugliness" mentioned&nbsp;for<br></div><div>&gt; classes.<br></div><div><=
br></div><div><br></div><div>Respectfully, I think `\` is ugly for both =
functions and classes.<br></div><div><br></div><div><br></div><div>&gt; =
Now, I know this would be a big BC break, but it brings consistency<br><=
/div><div>&gt; to the language and forces everyone to improve their code=
<br></div><div>&gt; performance.<br></div><div><br></div><div>There shou=
ld be a directive for this, like:<br></div><div><br></div><div>&nbsp;&nb=
sp;&nbsp; namespace foo using global functions;<br></div><div><br></div>=
<div>...which automatically acts as if all functions have a \ in front o=
f<br></div><div>them, unless they are fully qualified.<br></div><div><br=
></div></blockquote><div><br></div><div>Respectfully, I feel like this g=
ets into the heart of a problem with RFCs, where if someone wants to imp=
lement something, they have to solve everyone=E2=80=99s problems.<br></d=
iv><div><br></div><div>In this case, there is a problem with performance=
 issues due to multiple lookups (though, I=E2=80=99m not convinced fully=
), so if someone wants to implement function autoloading, they also have=
 to solve this problem (Gina and I have both independently solved it in =
various ways).<br></div><div><br></div><div>Personally, I=E2=80=99m of t=
he opinion that if you want performance, you know what to do: fully qual=
ify your names. If you don=E2=80=99t care (which is what I gather from t=
he first email in this thread where maintainers were not willing to chan=
ge their code), then =E2=80=9Cdeal with it.=E2=80=9D<br></div><div><br><=
/div><div>The vast majority of performance issues won=E2=80=99t be cause=
d by function lookups, but by databases and poorly written code. Maybe I=
 am wrong, but I rather like what we currently have, whatever benchmarks=
 have to say on the matter.&nbsp;</div><div><br></div><div id=3D"sig1212=
29152">=E2=80=94 Rob<br></div></body></html>
--ef75ea3718744f47819394c53f15de77--