Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124766
Precedence: bulk
MIME-Version: 1.0
References: <CAPyj-LCoBY2bPHLmsyONYDbY9aRSraLz5QNskeTiWfpMD0pTSg@mail.gmail.com>
 <73c0d611-16f6-ff3e-95a2-3c78c66d413d@php.net>
In-Reply-To: <73c0d611-16f6-ff3e-95a2-3c78c66d413d@php.net>
Date: Mon, 5 Aug 2024 15:15:46 +0200
Message-ID: <CAPyj-LDOdOyBKycHMovQ12=b3U4nVARTQGy9Spsc45a7uvseEA@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 Mon, Aug 5, 2024 at 1:23=E2=80=AFPM Derick Rethans <derick@php.net> wrot=
e:
>
> On Fri, 2 Aug 2024, Ilija Tovilo wrote:
>
> > As for providing a migration path: One approach might be to introduce
> > an INI setting that performs the function lookup in both local and
> > global scope at run-time, and informs the user about the behavioral
> > change in the future.
>
> That INI setting would control the *warning*, and not the
> *functionlity*, right?

Yes, that was my suggestion. First, in a future minor version, an INI
option could be added that would warn when finding both a local and
global function when performing an unqualified function call. The only
reason to hide this behind a setting is to avoid the cost of a double
lookup in production code when one isn't necessary, i.e. when calling
local functions in some namespace.

> I am surprised that it is that much of a performance benefit as well,
> but I am also concerned about the BC impact. But if that isn't too much,
> then I guess we need to consider this, but only for a major version. Not
> something I believe we can change in a 8.x version.

Sure, waiting for 9.0 sounds reasonable if we were to choose this approach.

Ilija