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.
```PHP
/** * 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/ - PSR-4 Example
Implementations: https://www.php-fig.org/psr/psr-4/examples/ - Old related
RFC: 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
----- 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.
