> On Mar 15, 2021, at 1:41 PM, Mark Randall <[email protected]> wrote:
>
> 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.
>
> https://wiki.php.net/rfc/autoload_classmap
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?
-----------
1. 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 {}
-----------
2. 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 call get_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.
-----------
3. 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.
