Quick summary:
Explore Krautoload as a solution for PSR-4 class loading.
About PSR-4 / PSR-X
The PHP-FIG group is discussing a new autoload standard, that will be an alternative to PSR-0 with
- more shallow directory structure.
- no more special handling of the underscore in the class name, and thus, no more backwards support for PEAR.
The working title is "PSR-X", the official title of the spec will probably be "PSR-4".
https://github.com/php-fig/fig-standards/blob/master/proposed/autoloader.md
It was suggested to adopt this for Drupal, even before the official PSR is released.
The main argument was a more DX-friendly directory structure, avoiding subfolder levels that are perceived as redundant.
#1971198: [meta] Drupal and PSR-0/PSR-4 Class Loading
Popular class loading solutions out there (Symfony, Composer) do not yet support the upcoming standard.
One obvious reason is that the standard is not released yet, and it is not entirely clear which name it will have.
The Krautoload library
Krautoload (github.com/donquixote/krautoload) has been suggested by donquixote as a possible solution for PSR-4 class loading in Drupal.
Some facts about the Krautoload library:
- It is a spin-off of the xautoload module, which currently has > 1000 happy users in D7, and rarely any issues.
- It is designed to compete with other popular class loaders, in every aspect. This means, everything it does differently is for a good reason.
- It supports PSR-4.
- It can handle different patterns aside of each other (PSR-4, PSR-0, PEAR, and different variations of these).
- It is fully aware of all the subtleties of PSR-0, that other loaders silently ignore. It is the user's choice whether to fully support those subtleties, or to take the same (tiny) risk as other loaders.
- It provides class discovery with different filesystem patterns (PSR-0, PSR-4).
- There are convenience methods to do typical composer stuff.
Performance:
- It is designed to perform well with a huge amount of namespaces, which is typical for Drupal.
- It has cache wrappers that are equivalent to Symfony's APC cache. (it does the exact same atomic operations, so should be equally performant)
- It (will have) a cache wrapper that builds a class map on the fly, that will be stored in the code generation folders. This thing will have a performance equivalent to any classmap stuff we could do with Composer, except that it will cover everything, not just core namespaces.
- Of course it can be wired up with an existing class map (although the registration phase could be speeded up).
- It may get an option to skip all registration steps at bootstrap, until the first cache miss. xautoload already has this in D7, so the idea should work.
- It avoids the (tiny) overhead of having more than one class loader on the stack.
- Benchmarks can be done with the Autoload benchmark sandbox module. Some intermediate results (already out of date, probably).
Caveats:
- It has no known user base (although xautoload has). The good thing is that we can heavily work on it without alienating the users.
- It is under heavy development, and already did change a lot since it was first proposed for Drupal a few days ago. The good thing is, this development goes hand in hand with the patches proposed for Drupal.
- Some things might change when PSR-4 comes out. However, we should be able to stabilize before D8 release.
- It needs more community contribution than existing solutions (although there is no "existing" solution for PSR-4 yet).
Status
In #1971198-135 it was shown that Krautoload can do the class loading part just fine.
In #1971198-144 we see an attempt to do the plugin discovery with Krautoload, because that needs to be converted to PSR-4 as well. There are still some issues to fix there.
Alternatives
It was suggested to use a hand-crafted PSR-4 loader, and do all the rest with Composer's class loader.
The composer loader would have a compiled class map for core classes.
This still needs a solution for plugin discovery.
Whether this is faster, only benchmarks can tell.
- Tiny (*) overhead of multiple loaders on the stack.
- No possibility for a unified cache layer.
Good thing would be:
- less work for us (but we still need to code a PSR-4 loader).
- some stuff that "will be" done in Krautoload is already done in Composer (although the "will be" could disappear within days).
- familiar interface (although Krautoload has compatibility layers)
- industry standard (except for our hand-crafted PSR-4)
(*) If we compare the performance of high-end class loaders, we are talking about small differences that are hard to measure. So, any tiny overhead can matter.
The alternative should be explored in a separate issue!