Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125159
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 23 Aug 2024 20:19:49 +0200
To: internals@lists.php.net
Message-ID: <b8f94f2d-e405-4298-b580-2a8c7e0c1ebb@app.fastmail.com>
In-Reply-To: 
 <CAPyj-LDCdo+UE0W1q6LOAVHrt6mVmGft9K4mBDvjkBWR3TT4kA@mail.gmail.com>
References: <21D6F160-5EAE-44FA-907B-E1DAAC1B8D75@rwec.co.uk>
 <53BD062A-4D7F-4E5D-852E-6D27641213A8@koalephant.com>
 <f32382b4-3bee-47ab-88ed-ad2ab154c319@app.fastmail.com>
 <7607FD64-5572-466E-9866-63C2536B2A09@koalephant.com>
 <0d269a38-28fe-494c-a903-50022e09f27b@app.fastmail.com>
 <E848530A-038F-40E0-A87D-D0C823C5E967@koalephant.com>
 <63DAE337-B117-4380-8735-186DC30FE0B7@rwec.co.uk>
 <CAPyj-LDCdo+UE0W1q6LOAVHrt6mVmGft9K4mBDvjkBWR3TT4kA@mail.gmail.com>
Subject: Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then
 local)
Content-Type: multipart/alternative;
 boundary=4892213702ba4cafbd2ec6af4a039e9a
From: rob@bottled.codes ("Rob Landers")

--4892213702ba4cafbd2ec6af4a039e9a
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Fri, Aug 23, 2024, at 19:32, Ilija Tovilo wrote:
> On Fri, Aug 23, 2024 at 5:49=E2=80=AFPM Rowan Tommins [IMSoP]
> <imsop.php@rwec.co.uk> wrote:
> >
> > Other proposals aim to shift that balance - leaving some inconsisten=
cy, but less compatibility break.
> >
> > And most users don't object to using a leading backslash, they just =
(quite reasonably) have no idea what impact it has on the ability of the=
 engine to optimise their code.
>=20
> For some context: Before proposing this change, I asked Symfony if
> they were interested in disambiguating calls to improve performance,
> given I did some work to make fully qualified calls faster. But they
> were not, stating that the change would be too verbose for their
> liking.

I think if someone values code beauty more than speed, they can do that.=
 Although, I find that rather hilarious when their code base is littered=
 with goto, =E2=80=9Cfor speed.=E2=80=9D

What it really sounds like is that they realized you would just change t=
he language and they wouldn=E2=80=99t have to review those changes=E2=80=
=A6 /s

>=20
> Making unqualified calls to mean local would force Symfony into making
> the change, which is not the approach I'm interested in taking. Making
> them global would likely reduce breakage by much, but not nearly as
> much as keeping the fallback.

I don=E2=80=99t think changing the language for a specific framework(s) =
is a good idea.

>=20
> From reading the responses, it seems we have three primary camps:
>=20
> 1. People who don't think BC is a problem, and would like to drop
> either the global or local lookup entirely, requiring disambiguation.
> 2. People who do think BC is a problem, and would like some opt-in
> mechanism to explicitly pick global or local scope.
> 3. People who aren't convinced that the performance improvements are
> worth it to begin with, or that the developers themselves are
> responsible for disambiguation.
>=20
> IMO, 1. is too drastic. As people have mentioned, there are tools to
> automate disambiguation. But unless we gain some other benefit from
> dropping the lookup entirely, why do it? Consistency with class
> lookups is a factor, but is it enough to break a large portion of
> codebases? The summed up time of every maintainer installing and
> running a tool that modifies a large portion of the codebase, and then
> dealing with conflicts in existing branches is not miniscule. Fixing
> local calls will also require context from other files to correctly
> disambiguate. I'm not aware if any tools actually consider context, or
> just take the naive approach of making known, internal calls global,
> and leaving the rest.

Aren=E2=80=99t we doing that anyway with your proposal? Sure, maybe that=
 doesn=E2=80=99t require (much) changes, right now. But there is an RFC =
being discussed right now which introduces a new function called =E2=80=9C=
parse_html=E2=80=9D

This seems like a super generic name that did not take global-first into=
 account. I know for a fact I have seen code with that exact function na=
me several times in my career.

>=20
> 2. misses the point of the immediate performance gains without
> modifications to the codebase. Even if the disambiguation itself is a
> one-liner, it still needs to be added to every codebase and every
> file, and still requires fixing actual local calls that may be made
> within the same file.
>=20
> I obviously also disagree with 3. as I wouldn't have sent this
> proposal otherwise. :) Performance improvements are hard to come by
> nowadays. It was measured on real codebases (Symfony and Laravel).
>=20
> Ilija
>=20

Applications are more likely to get better performance gains in symfony =
by uninstalling doctrine and writing optimized queries, to be completely=
 honest.

=E2=80=94 Rob
--4892213702ba4cafbd2ec6af4a039e9a
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 Fri, Aug 23, 2024, at 19:32, Ilija Tovilo wrote:<br></=
div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On Fri, Aug 23, =
2024 at 5:49=E2=80=AFPM Rowan Tommins [IMSoP]<br></div><div>&lt;<a href=3D=
"mailto:imsop.php@rwec.co.uk">imsop.php@rwec.co.uk</a>&gt; wrote:<br></d=
iv><div>&gt;<br></div><div>&gt; Other proposals aim to shift that balanc=
e - leaving some inconsistency, but less compatibility break.<br></div><=
div>&gt;<br></div><div>&gt; And most users don't object to using a leadi=
ng backslash, they just (quite reasonably) have no idea what impact it h=
as on the ability of the engine to optimise their code.<br></div><div><b=
r></div><div>For some context: Before proposing this change, I asked Sym=
fony if<br></div><div>they were interested in disambiguating calls to im=
prove performance,<br></div><div>given I did some work to make fully qua=
lified calls faster. But they<br></div><div>were not, stating that the c=
hange would be too verbose for their<br></div><div>liking.<br></div></bl=
ockquote><div><br></div><div>I think if someone values code beauty more =
than speed, they can do that. Although, I find that rather hilarious whe=
n their code base is littered with goto, =E2=80=9Cfor speed.=E2=80=9D</d=
iv><div><br></div><div>What it really sounds like is that they realized =
you would just change the language and they wouldn=E2=80=99t have to rev=
iew those changes=E2=80=A6 /s<br></div><div><br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div><br></div><div>Making unqualified calls=
 to mean local would force Symfony into making<br></div><div>the change,=
 which is not the approach I'm interested in taking. Making<br></div><di=
v>them global would likely reduce breakage by much, but not nearly as<br=
></div><div>much as keeping the fallback.<br></div></blockquote><div><br=
></div><div>I don=E2=80=99t think changing the language for a specific f=
ramework(s) is a good idea.</div><div><br></div><blockquote type=3D"cite=
" id=3D"qt" style=3D""><div><br></div><div>From reading the responses, i=
t seems we have three primary camps:<br></div><div><br></div><div>1. Peo=
ple who don't think BC is a problem, and would like to drop<br></div><di=
v>either the global or local lookup entirely, requiring disambiguation.<=
br></div><div>2. People who do think BC is a problem, and would like som=
e opt-in<br></div><div>mechanism to explicitly pick global or local scop=
e.<br></div><div>3. People who aren't convinced that the performance imp=
rovements are<br></div><div>worth it to begin with, or that the develope=
rs themselves are<br></div><div>responsible for disambiguation.<br></div=
><div><br></div><div>IMO, 1. is too drastic. As people have mentioned, t=
here are tools to<br></div><div>automate disambiguation. But unless we g=
ain some other benefit from<br></div><div>dropping the lookup entirely, =
why do it? Consistency with class<br></div><div>lookups is a factor, but=
 is it enough to break a large portion of<br></div><div>codebases? The s=
ummed up time of every maintainer installing and<br></div><div>running a=
 tool that modifies a large portion of the codebase, and then<br></div><=
div>dealing with conflicts in existing branches is not miniscule. Fixing=
<br></div><div>local calls will also require context from other files to=
 correctly<br></div><div>disambiguate. I'm not aware if any tools actual=
ly consider context, or<br></div><div>just take the naive approach of ma=
king known, internal calls global,<br></div><div>and leaving the rest.<b=
r></div></blockquote><div><br></div><div>Aren=E2=80=99t we doing that an=
yway with your proposal? Sure, maybe that doesn=E2=80=99t require (much)=
 changes, right now. But there is an RFC being discussed right now which=
 introduces a new function called =E2=80=9Cparse_html=E2=80=9D<br></div>=
<div><br></div><div>This seems like a super generic name that did not ta=
ke global-first into account. I know for a fact I have seen code with th=
at exact function name several times in my career.<br></div><div><br></d=
iv><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div>2.=
 misses the point of the immediate performance gains without<br></div><d=
iv>modifications to the codebase. Even if the disambiguation itself is a=
<br></div><div>one-liner, it still needs to be added to every codebase a=
nd every<br></div><div>file, and still requires fixing actual local call=
s that may be made<br></div><div>within the same file.<br></div><div><br=
></div><div>I obviously also disagree with 3. as I wouldn't have sent th=
is<br></div><div>proposal otherwise. :) Performance improvements are har=
d to come by<br></div><div>nowadays. It was measured on real codebases (=
Symfony and Laravel).<br></div><div><br></div><div>Ilija<br></div><div><=
br></div></blockquote><div><br></div><div>Applications are more likely t=
o get better performance gains in symfony by uninstalling doctrine and w=
riting optimized queries, to be completely honest.<br></div><div><br></d=
iv><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body></html>
--4892213702ba4cafbd2ec6af4a039e9a--