PSR-4 has been the community standard for autoloading namespaced classes since 2014 and is used by virtually every modern PHP package via Composer. However, the actual autoloading still requires userspace code: spl_autoload_register() with a closure or class method (almost always generated by Composer) that performs prefix matching and file_exists/require.
This RFC proposes adding a small set of native functions that allow the engine itself to perform PSR-4 autoloading directly from registered prefix → base directory mappings. Package managers and applications can opt into the faster, engine-native path instead of (or in addition to) registering a userspace callback.
With emphasis on PSR-4 compliance, the engine implementation MUST follow the PSR-4 specification exactly for prefix matching, relative path construction, file extension (.php), and case sensitivity of the terminating class name.
This can provide a performance improvement for PSR-4 heavy workloads by eliminating userspace callback overhead.
To fully support PSR-4 autoloading I would propose a function spl_autoload_psr4_register and complimenting functions.
Here is a proposed API.
/** * Register a PSR-4 namespace prefix → base directory mapping for native engine autoloading. * * @param string $prefix Namespace prefix (trailing \ recommended; will be normalized) * @param string|array $baseDirs One base directory (string) or list of base directories (array) * @param bool $prepend Insert at front of search order (like spl_autoload_register) * @return bool True on success */ function spl_autoload_psr4_register(string $prefix, string|array $baseDirs, bool $prepend = false): bool {}
/** * Remove a previously registered PSR-4 prefix (and its base directories). */ function spl_autoload_psr4_unregister(string $prefix): bool {}
/** * Enable/disable the native PSR-4 fast path. When disabled, mappings are kept but ignored. */ function spl_autoload_psr4_enable(bool $enable = true): void {}
/** * Whether the native PSR-4 mechanism is currently active. */ function spl_autoload_psr4_enabled(): bool {}
/** * Return current mappings as [prefix => [baseDir, ...], ...] preserving registration order. */ function spl_autoload_psr4_get_mappings(): array {} ``` There would be no backwards compatibility issues and a simple `function_exists('spl_autoload_psr4_register')` call would be used to trigger use of the new functionality or fallback to userland callback register.
Discussion points:
Should there be an `spl_autoload_psr4_enable(bool)` function to enable this functionality or should the usage of `spl_autoload_psr4_register` auto-enable the autoloader?
References
- PSR-4 Specification: [https://www.php-fig.org/psr/psr-4/](https://www.php-fig.org/psr/psr-4/) - PSR-4 Example Implementations: [https://www.php-fig.org/psr/psr-4/examples/](https://www.php-fig.org/psr/psr-4/examples/) - Old related RFC: [https://wiki.php.net/rfc/splclassloader](https://wiki.php.net/rfc/splclassloader) (declined, PSR-0 focused) - Composer Autoloader class: [https://github.com/composer/composer/blob/main/src/Composer/Autoload/ClassLoader.php](https://github.com/composer/composer/blob/main/src/Composer/Autoload/ClassLoader.php) ----- This idea originally spawned from my idea to try an eliminate the standard bootstrapping call of `include_once(__DIR__ . '/vendor/autoload.php')` While this does not achieve this, i believe it can be a good first step.