On Sun, 2024-08-04 at 19:53 +0200, Ilija Tovilo wrote:
> Hi Claude
>
> On Fri, Aug 2, 2024 at 9:02 PM Claude Pache <[email protected]>
> wrote:
> >
> > I propose the following alternative approach:
> >
> > * establish a restricted whitelist of global functions for which
> > the performance gain would be noteworthy if there wasn’t any need
> > to look at local scope first;
> >
> > * for those functions, disallow to define a function of same name
> > in any namespace, e.g.: https://3v4l.org/RKnZt
> >
> > That way, those functions could be optimised, but the current
> > semantics of namespace lookup would remain unchanged.
>
> 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.
>
> 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.