Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125154
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <63DAE337-B117-4380-8735-186DC30FE0B7@rwec.co.uk>
Date: Fri, 23 Aug 2024 19:32:41 +0200
Message-ID: <CAPyj-LDCdo+UE0W1q6LOAVHrt6mVmGft9K4mBDvjkBWR3TT4kA@mail.gmail.com>
Subject: Re: [PHP-DEV] [Concept] Flip relative function lookup order (global,
 then local)
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

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 inconsistency, b=
ut less compatibility break.
>
> And most users don't object to using a leading backslash, they just (quit=
e reasonably) have no idea what impact it has on the ability of the engine =
to optimise their code.

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.

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.

From reading the responses, it seems we have three primary camps:

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.

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.

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.

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).

Ilija