[PHP-DEV] Pre-RFC spitball - Namespace Load event

This is tangential to the function autoload discussion.

An idea that popped into my head an hour ago, that I don’t have another PHP Dev to talk to about, what if you could register a function that is called by PHP the first time it sees a namespace declared?

This would allow functions and for that matter constants of the namespace to be declared before they get called. It isn’t as clean as waiting until the function call itself is being called, but maybe that’s for the best. After all, if you have a dozen 10 line utility functions do you necessarily want 10 files.

Again, I don’t know the engine, but this doesn’t seem like this would be that hard to do. Note that how autoloaders register themselves to this function, resolve what to load and so on is a separate can of worms.

As to what to call it, maybe spl_namespace_register($callback, $prepend). The callback gets the string of the namespace that PHP just saw for the first time and it gets to execute before any code in that namespace gets to execute.

Thoughts?

Le 02/07/2026 à 16:41, Michael Morris a écrit :

This is tangential to the function autoload discussion.

An idea that popped into my head an hour ago, that I don't have another PHP Dev to talk to about, what if you could register a function that is called by PHP the first time it sees a namespace declared?

This would allow functions and for that matter constants of the namespace to be declared before they get called. It isn't as clean as waiting until the function call itself is being called, but maybe that's for the best. After all, if you have a dozen 10 line utility functions do you necessarily want 10 files.

Again, I don't know the engine, but this doesn't seem like this would be that hard to do. Note that how autoloaders register themselves to this function, resolve what to load and so on is a separate can of worms.

As to what to call it, maybe spl_namespace_register($callback, $prepend). The callback gets the string of the namespace that PHP just saw for the first time and it gets to execute before any code in that namespace gets to execute.

Thoughts?

Interesting idea, not sure whether it's viable or not.

As of how I understand it, there are multiple ways to do this and all of them will imply different ways developers can use such feature.

With the namespace order, for instance, imagine the very first namespace declaration is "namespace Foo\Bar\Baz;": what is the order of declarations that will be sent to callbacks?

  * Will the callbacks receive "Foo\Bar\Baz" as argument directly and be
    called only once?
  * Will they be called once per sub-namespace? If yes, will it be like
    calling the callback three times, like this: `$callback('Foo');
    $callback('Foo\\Bar'); $callback('Foo\\Bar\\Baz'); `
  * How should it propagate if other sub-namespaces of these namespaces
    are declared? Like, if you have statements like "namespace Foo\Bar
    {} namespace Foo\Baz {}" , would it call registered callbacks like
    "Foo -> Foo\Bar -> Foo\Baz", or should it do like no1 and just go
    with "Foo\Bar -> Foo\Baz"?
  * Or something else?

There might be other issues, but that's my "hot reaction" when reading your suggestion :slight_smile:

On Fri, Jul 3, 2026 at 4:15 AM Alex Rock <pierstoval@gmail.com> wrote:

Le 02/07/2026 à 16:41, Michael Morris a écrit :

This is tangential to the function autoload discussion.

An idea that popped into my head an hour ago, that I don’t have another PHP Dev to talk to about, what if you could register a function that is called by PHP the first time it sees a namespace declared?

This would allow functions and for that matter constants of the namespace to be declared before they get called. It isn’t as clean as waiting until the function call itself is being called, but maybe that’s for the best. After all, if you have a dozen 10 line utility functions do you necessarily want 10 files.

Again, I don’t know the engine, but this doesn’t seem like this would be that hard to do. Note that how autoloaders register themselves to this function, resolve what to load and so on is a separate can of worms.

As to what to call it, maybe spl_namespace_register($callback, $prepend). The callback gets the string of the namespace that PHP just saw for the first time and it gets to execute before any code in that namespace gets to execute.

Thoughts?

Interesting idea, not sure whether it’s viable or not.

As of how I understand it, there are multiple ways to do this and all of them will imply different ways developers can use such feature.

With the namespace order, for instance, imagine the very first namespace declaration is “namespace Foo\Bar\Baz;”: what is the order of declarations that will be sent to callbacks?

  • Will the callbacks receive “Foo\Bar\Baz” as argument directly and be called only once?

Hmm.. Good question. I think one call, with Foo\Bar\Baz, because the goal is to have a hook so user code can initiate the referencing of that name space. It would be up to the callback to sort out what to do - the engine need only give opportunity.

And this applies for use statements as well. For example, if use A\foo; is foo a class? a function, a constant? Who knows, but this is the moment to find out and execute this handler.

Or, perhaps, change the use statement so that it explicitly fires a callback if the referenced chain doesn’t already exist. That, however, creates some overlap to spl_autoload_register, but it might be cleaner all the same. Calling in functions of a namespace could get JavaScript levels of obnoxious and runs against the grain of PHP, but this could be eased with wildcard loading use A\* telling the callback to load all symbols related to A explicitly.

Maybe this should be tied to use and not to namespace entirely? No - I don’t think so, this isn’t intuitive

namespace A;
use A/*;

So I’m thinking both will be needed.

  • Will they be called once per sub-namespace? If yes, will it be like calling the callback three times, like this: $callback('Foo'); $callback('Foo\\Bar'); $callback('Foo\\Bar\\Baz');
  • How should it propagate if other sub-namespaces of these namespaces are declared? Like, if you have statements like “namespace Foo\Bar {} namespace Foo\Baz {}” , would it call registered callbacks like “Foo → Foo\Bar → Foo\Baz”, or should it do like no1 and just go with “Foo\Bar → Foo\Baz”?
  • Or something else?

I think some coordination with the engine will be needed, not necessarily required but for optimization definitely needed.

The engine will track which namespaces it has given the callback the opportunity to set up. The callback, by returning an array, can tell the engine what namespaces it has set up. So on namespace A\B\C; The callback could return [‘A’, ‘A\B’, ‘A\B\C’, ‘A\D’, ‘A\D\E’] because it knows those other sub namespaces exist and doesn’t need to be pestered about them in the future.

Use statements will need to assume the last symbol encountered is a class, constant or function and step over it. So

namespace B;
use C\foo;
use D\*;

Breaking down, the engine could end up firing the callback three times. However, when the callback is made for B it could, for whatever reason, register C and D as well, run their setups and mark them off - tell the engine it’s done that so the other two firings would be skipped.

Further thinking on the second use statement above - the callback gets namespace ‘D’ and needs to set it up. But, this is also an opportunity to change the load order. Say D has a strpos statement for whatever reason - the use D* would cause the D namespace to be checked before the root namespace. I believe the current namespace is also always checked before the root as well.

This callback could give us a logical place to tell the engine to reverse this - check root before checking local for a given namespace.

There might be other issues, but that’s my “hot reaction” when reading your suggestion :slight_smile:

Thanks. Again, this is an idea I haven’t really sussed out all the corner cases. It just struck me as something that could be useful and the more I look at it the more useful it seems - but symbol loading is a vital and complicated part of the engine and it definitely needs brainstorming before any RFC to change it in any way.

Hi Michael,

On Jul 2, 2026, at 09:41, Michael Morris <tendoaki@gmail.com> wrote:

This is tangential to the function autoload discussion.

An idea that popped into my head an hour ago, that I don't have another PHP Dev to talk to about, what if you could register a function that is called by PHP the first time it sees a namespace declared?

That's a neat idea ...

This would allow functions and for that matter constants of the namespace to be declared before they get called. It isn't as clean as waiting until the function call itself is being called, but maybe that's for the best. After all, if you have a dozen 10 line utility functions do you necessarily want 10 files.

... but do note that function autoloading need not be 1-file-per-function, as is the typical case with classes (cf. PSR-0 and PSR-4). For example, the Moto autoloader allows more-than-one class or function per file.

  GitHub - motophp/autoload: More-than-one class-per-file autoloader for PHP. · GitHub

That's only one option for multiples-per-file, so that those "dozen 10 line utility functions" can be in a single file.

-- pmj

On Fri, Jul 3, 2026 at 8:50 AM Paul M. Jones <pmjones@pmjones.io> wrote:

Hi Michael,

On Jul 2, 2026, at 09:41, Michael Morris <tendoaki@gmail.com> wrote:

This is tangential to the function autoload discussion.

An idea that popped into my head an hour ago, that I don’t have another PHP Dev to talk to about, what if you could register a function that is called by PHP the first time it sees a namespace declared?

That’s a neat idea …

This would allow functions and for that matter constants of the namespace to be declared before they get called. It isn’t as clean as waiting until the function call itself is being called, but maybe that’s for the best. After all, if you have a dozen 10 line utility functions do you necessarily want 10 files.

… but do note that function autoloading need not be 1-file-per-function, as is the typical case with classes (cf. PSR-0 and PSR-4). For example, the Moto autoloader allows more-than-one class or function per file.

https://github.com/motophp/autoload

That’s only one option for multiples-per-file, so that those “dozen 10 line utility functions” can be in a single file.

– pmj

How autoloaders/callbacks use this hook is independent of the hook implementation itself. It does need to be kept in mind, but it also doesn’t need to be addressed directly in any RFC that rises out of this.

On Fri, Jul 3, 2026, at 7:32 AM, Michael Morris wrote:

And this applies for use statements as well. For example, if `use
A\foo;` is foo a class? a function, a constant? Who knows, but this is
the moment to find out and execute this handler.

It's known because the syntax says what it is.

use Foo\Bar; // Bar is a class, or a namespace prefix.
use function Foo\Bar\baz; // baz is a function.
use const Foo\Bar\Beep; // Beep is a constant.

This feels somewhat similar to Python, where a given module can have an __init__.py file that is automatically loaded the first time the module is referenced. I'm not sure how well that maps into PHP (see previous module/package/namespace threads), but it's an interesting model to explore for function autoloading.

--Larry Garfield

On Fri, Jul 3, 2026 at 12:35 PM Larry Garfield <larry@garfieldtech.com> wrote:

On Fri, Jul 3, 2026, at 7:32 AM, Michael Morris wrote:

And this applies for use statements as well. For example, if use A\foo; is foo a class? a function, a constant? Who knows, but this is
the moment to find out and execute this handler.

It’s known because the syntax says what it is.

use Foo\Bar; // Bar is a class, or a namespace prefix.
use function Foo\Bar\baz; // baz is a function.
use const Foo\Bar\Beep; // Beep is a constant.

I had forgotten about that. It may simplify things then. Hmm…

This feels somewhat similar to Python, where a given module can have an init.py file that is automatically loaded the first time the module is referenced. I’m not sure how well that maps into PHP (see previous module/package/namespace threads), but it’s an interesting model to explore for function autoloading.

–Larry Garfield

I was aware of the Python approach, but I’m also aware of how beloved magic file names are in PHP (as in, not - see the argument over treating an extension differently, let alone a reserved file name).

Anyway, the main reason I brought this up is I cannot recall this exact approach being discussed before. I don’t have the expertise to determine if the path is viable.