This document lists the pros and cons of the various autoloading mechanisms existing in
the PHP world.

Most PHP autoloaders available today follow the PSR
conventions and, as such, belong to the family of path-based autoloaders.
A path-based autoloader uses the symbol name to locate the script file defining the symbol.

the developer builds a map file using the build software (in CLI mode). The map file becomes an integral part of the application.

At runtime, the map file is loaded using the Automap runtime. Then, when a symbol is not found, the Automap autoloader uses its registered maps to load the appropriate script file.

This table lists the pros and cons of both approaches:

Path-based

Map-based

Generally quite slow because resolving symbols requires a lot of file system I/O.

This often represents a significant, if not major, part of the request execution time.

Unfortunately, improving runtime performance on a path-based autoloader is very complex because, by design, it requires a lot of disk I/O.

Very fast. Works in memory and loads the appropriate script using its absolute path. Resolving a symbol to a path does not require any disk I/O.

Loading very large maps at the beginning of every request may be an issue, especially if the application uses few symbols.
Automap uses an optimized two-level loading mechanism to minimize this overhead.
When using the optional PECL extension, the map load time is almost null because
maps are cached in persistent memory.

Does not require running anything when new files and symbols are added to the code base.

This makes it more flexible for development environments.

Requires to rebuild the map when new symbols are defined.

File/directory naming must follow a precise convention.

If an existing project wants to switch to a path-based autoloader, its file tree must be made compliant with PSR requirements first.

Major issue for projects with a
large code base, or/and many contributors, used to the project's way of naming files and directories.

Supports only one symbol definition per script file.

Does not impose any restriction on the number of symbols defined in a single
script file.

Case sensitivity depends on the OS environment: PHP classes
are supposed to be case-insensitive but, on a case sensitive file system (as
every Unix/Linux OS), a path-based autoloader cannot behave in a case-insensitive
way.

The only solution, in theory, would be that every file
and directory names are fully lowercase, which is incompatible with PSR naming
standards (and, with underscores disabled, unreadable).

The biggest issue is
not to be case-sensitive or not. It is that autoloaders behave differently under
different environments, typically Windows and Unix/Linux. Using exactly the same
code base, a path-based autoloader is always case-insensitive on Windows and
always case-sensitive on Linux. For typical environments where development is
done under Windows and production runs on Linux, this leads to errors showing up
when switching to production and impossible to discover before.

Starting with version 3.0.0, Automap is fully case-sensitive, whatever environment it is running on. This was chosen because we now consider
case mismatch in class names as typos that must be detected as soon as possible.

However, the important point here is that Automap provides a consistent behavior on every environment.

A future extension of the PHP interpreter to support function and constant
autoloading would bring several issues and incompatibilities:

The 'one symbol per file' rule becomes too restrictive.

Supporting several symbol types would require to include the symbol type somewhere
in the file path.

constants are case-sensitive, which cannot be implemented on a case-insensitive
file system (Windows).

Actually, these constrainsts and incompatibilities are the main reasons why PHP autoloading was not extended to functions and constants yet.

Can easily manage different symbol types, as it just needs
to recognize them when scanning the code.

Automap already registers functions and constants, along with classes, when scanning PHP scripts, even if the PHP engine is not ready to autoload them yet.

In the future, extending PHP autoloading to functions and constants could be done with total backwards compatibility (requiring no change to existing autoloaders).