Hi Internals,
I would like to propose the addition of a new mechanism of autoloading classes - a classmap that will be consulted prior to checking the spl_autoload_register'd callbacks.
Yes, please! This would be a real treat for those whose use-cases do not fit nicely into the PSR-4 standard (like WordPress plugins.)
However, may I discuss some additions?
- Sometimes it is inconvenient to set the entire class-map. For example, a WordPress plugin might want to add all of its files to the autoloader and let other plugins handle their own needs.
While that could be done with your get() and set() functions along with an array merge, it would be clearer in userland just to have an add().
Further, when there are tens of plugins then adding the files for each plugin could be a lot of userland array manipulation that I assume could be done more efficiently within a core function.
So, I would propose including a third function that would add to the current classmap rather than just replace it like set():
autoload_add_classmap(mapping $array): void {}
- There has been numerous times when I wanted to monitor when classes are loaded. I have been reduced to calling
get_declared_classes()before require_once() and then callget_declared_classes()again after and slice off the difference between the two, which I assume is very costly.
If would be great is the autoloader could call a callable and pass the list of classes that were loaded, assuming such as callable exists.
So, I would propose including a third function that would add to the current classmap rather than just replace it like set():
autoload_set_classmap_listener(callable $listener): void {}
autoload_get_classmap_listener(): callable {}
This might be tangential to your RFC but if we are updating the autoloader already this addition might be trivial.
- Based upon the above and the existing spl_() functions I would ask it it would not make sense to create an interface called "Loader" and a set of classes to support autoloading instead, and then deprecate the spl_() at some distant point in the future?
To provide something to make it easier to consider this approach I created a strawman Gist using PHP code to illustrate the idea. It is not a complete working example, and likely not fully fleshed out either, but it should work as a starting point for discussion:
https://gist.github.com/mikeschinkel/2ff8b5f78e88688dbbadb41a762c119f https://gist.github.com/mikeschinkel/2ff8b5f78e88688dbbadb41a762c119f
Note that using an interface like this would allow developers to create their own custom autoloaders as classes and/or we could implement a PSR-4 specific autoloader class in the future directly in core that could work with this configuration (and maybe even a PSR-1 autoloader in core.)
-Mike
P.S. The interface and classes example uses the controversial "PHP" namespace, but please let us not fixate on that. Let us instead discuss if an interface and set of classes makes sense and if so figure out the right namespace afterwards.