Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124746
Message-ID: <42fa20172d236a719a69c1ccf97e0c97cdce6976.camel@ageofdream.com>
Subject: Re: [PHP-DEV] [Concept] Flip relative function lookup order
 (global, then local)
To: internals@lists.php.net
Date: Sun, 04 Aug 2024 14:07:27 -0400
In-Reply-To: <CAPyj-LA1YqmVEc7SwXZGtaFi=qOMOswOyZVkdFm_8SOYpv644A@mail.gmail.com>
References: 
	<CAPyj-LCoBY2bPHLmsyONYDbY9aRSraLz5QNskeTiWfpMD0pTSg@mail.gmail.com>
	 <18D4B0E8-F71F-4FCD-87E1-E5E3C4CA5068@gmail.com>
	 <CAPyj-LA1YqmVEc7SwXZGtaFi=qOMOswOyZVkdFm_8SOYpv644A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4-2 
Precedence: bulk
MIME-Version: 1.0
From: lists@ageofdream.com (Nick Lockheart)

On Sun, 2024-08-04 at 19:53 +0200, Ilija Tovilo wrote:
> Hi Claude
>=20
> On Fri, Aug 2, 2024 at 9:02=E2=80=AFPM Claude Pache <claude.pache@gmail.c=
om>
> wrote:
> >=20
> > I propose the following alternative approach:
> >=20
> > * establish a restricted whitelist of global functions for which
> > the performance gain would be noteworthy if there wasn=E2=80=99t any ne=
ed
> > to look at local scope first;
> >=20
> > * for those functions, disallow to define a function of same name
> > in any namespace, e.g.: https://3v4l.org/RKnZt
> >=20
> > That way, those functions could be optimised, but the current
> > semantics of namespace lookup would remain unchanged.
>=20
> That would be an improvement over the status quo. However, if you
> look
> at the bullet points in my original email, while some of the
> optimizations apply only to some functions (CTE, custom opcodes and
> frameless calls), others apply to all internal, global functions
> (double-lookup, lookup by offset, specialized argument passing).
> Hence, we may only get a fraction of the benefits by restricting the
> optimization to a handful of functions. I also wonder if the impact
> is
> actually bigger, as then there's no workaround for redeclaring the
> function, requiring much bigger refactoring.
>=20
> Ilija

Also, overriding any default function is one of the benefits of name
spacing in the first place. If we say, "built-in functions can't be
overridden, then you are basically saying that all built-in functions
are global.

But there is a valid use case for overriding built-ins. You may want to
disable built-in functionality with a stub for unit testing.

There should probably be a per-file way of setting the default either
way without ns lookups.

use global functions
- or -
use local functions
- or -
omit directive to use dynamic NS lookup for BC.