Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125175
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>
 <CAPyj-LDCdo+UE0W1q6LOAVHrt6mVmGft9K4mBDvjkBWR3TT4kA@mail.gmail.com> <977227E3-8793-4FB1-B572-B75D27C06ED5@rwec.co.uk>
In-Reply-To: <977227E3-8793-4FB1-B572-B75D27C06ED5@rwec.co.uk>
Date: Fri, 23 Aug 2024 23:57:12 +0200
Message-ID: <CAPyj-LDra0K+hi+80swpWJJp4-t7NT3s9ufC1jfH2x5O7-P0dw@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 9:41=E2=80=AFPM Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> wrote:
>
> On 23 August 2024 18:32:41 BST, Ilija Tovilo <tovilo.ilija@gmail.com> wro=
te:
> >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?
>
> I can think of a few disadvantages of "global first":
>
> - Fewer code bases will be affected, but working out which ones is harder=
. The easiest migration will probably be to make sure all calls to namespac=
ed functions are fully qualified, as though it was "global only".

To talk about more concrete numbers, I now also analyzed how many
relative calls to local functions there are in the top 1000 composer
packages.

https://gist.github.com/iluuu1994/9d4bbbcd5f378d221851efa4e82b1f63

There were 4229 calls to local functions that were statically visible.
Of those, 1534 came from thecodingmachine/safe, which I'm excluding
again for a fair comparison. The remaining 2695 calls were split
across 210 files and 27 repositories, which is less than I expected.

The calls that need to be fixed by swapping the lookup order are a
subset of these calls, namely only the ones also clashing with some
global function. Hence, the process of identifying them doesn't seem
fundamentally different. Whether the above are "few enough" to justify
the BC break, I don't know.

> - The engine won't be able to optimise calls where the name exists locall=
y but not globally, because a userland global function could be defined at =
any time.

When relying on the lookup, the lookup will be slower. But if the
hypothesis is that there are few people relying on this in the first
place, it shouldn't be an issue. It's also worth noting that many of
the optimizations don't apply anyway, because the global function is
also unknown and hence a user function, with an unknown signature.

> - Unlike with the current way around, there's unlikely to be a use case f=
or shadowing a namespaced name with a global one; it will just be a gotcha =
that trips people up occasionally.

Indeed. But this is a downside of both these approaches.

> None of these seem like showstoppers to me, but since we can so easily go=
 one step further to "global only", and avoid them, why wouldn't we?
>
> Your answer to that seems to be that you think "global only" is a bigger =
BC break, but I wonder how much difference it really makes. As in, how many=
 codebases are using unqualified calls to reference a namespaced function, =
but *not* shadowing a global name?

I hope this provides some additional insight. Looking at the analysis,
I'm not completely opposed to your approach. There are some open
questions. For example, how do we handle functions declared and called
in the same file?

namespace Foo;
function bar() {}
bar();

Without a local fallback, it seems odd for this call to fail. An
option might be to auto-use Foo\bar when it is declared, although that
will require a separate pass over the top functions so that functions
don't become order-dependent.

Ilija