> On 16 Mar 2021, at 20:07, Jordi Boggiano <j.boggiano@seld.be> wrote:
>
> Hey,
>
> Here some perspective on this from the Composer side of things. To the best of my knowledge the
> Composer autoloader is the default autoloader used by most PHP projects at this point except for
> WordPress. I am sure there are a few more outliers and people using custom autoloaders in addition
> of, or instead of the Composer-generated one, but generally speaking it has supplanted many custom
> implementations in frameworks over the years.
>
> First of all big +1 here, if we can make things faster for non-preloaded workloads it's
> great. The autoloader is definitely a big fixed "infrastructure cost" in many such apps
> currently, and I don't think we can squeeze any more perf from userland.
>
> On 15/03/2021 19:32, Mark Randall wrote:
>> On 15/03/2021 17:59, Levi Morrison via internals wrote:
>>> IMO, these should be the defined case of the class, or we should be
>>> insensitive about it. It's one thing that our symbols are case
>>> insensitive; it is wholly another to _require_ it for this feature by
>>> requiring lowercase names. I assume there is some motivation for this;
>>> I would like to hear it.
>>
>> EG(class_table) is stored lowercase, the case of the class name itself is only known once
>> it has been found which could only occur after the autoloader has run.
>>
>> By forcing lowercase we have a single key to lookup for any variation, without it we would
>> have to either match the case exactly (which would be different from how internals currently works)
>> or would have to iterate over every item in the classmap array each time, performing case a
>> insensitive comparisons on every key until one was found, or in the worst case, the entire set.
>
> - The Composer ClassLoader [1] uses a case-sensitive classmap which overall has not caused
> major issues except when people do class_exists or new calls with the wrong case. That said, if we
> were to support this new API we would for sure be able to generate a lowercased classmap, we just
> haven't done it until now because spl_register_autoload calls the callback with the original
> case, and having to lowercase the passed class name on every call seemed wasteful. If internals
> already does this anyway that sounds fine by me.
>
> - It also uses include vs the proposed require_once in this RFC. I am not entirely
> sure what the implications are here, nor if there are still performance differences to one over the
> other, but IIRC we do include because it's the fastest, and as a class never gets autoloaded
> twice a file does not really risk being included again.
>
> - Right now we have to run includes through a proxy function [2] to avoid granting the included
> file access to $this and other in-scope variables. It's not that much overhead but can quickly
> lead to a thousand extra function calls within a request's lifecycle, so just for completeness
> I figured I'd mention it.
>
> - As Mike Schinkel mentioned, the proposed API should really support multiple maps. Composer a
> prepend-autoloader option which controls whether the generated autoloader will be prepended or
> appended when spl_autoload_register is called. This is required in some cases where multiple
> autoloaders coexist. So the ability to add multiple maps, including optionally prepending them would
> be a must IMO. The ability to remove an autoloader and its associated classmap would also be very
> welcome so one can unregister things cleanly.
>
> So taking the above in consideration, and keeping consistency with existing spl_* functions in
> mind, I would propose an API more like:
>
> autoload_register_classmap(array $map, bool $prepend = false)
> autoload_unregister_classmap(array $map)
>
>
> P.S: While I am here looking at spl_* docs, it seems to me like spl_autoload_call should be
> deprecated in favor of class_exists, and spl_autoload_extensions + spl_autoload also probably should
> be deprecated or at least marked as antiquated in the docs, and not migrated to autoload_* like you
> suggested doing for spl_autoload_register/unregister in another RFC.
>
> [1] https://github.com/composer/composer/blob/b6826f352390b4c952be8fd75d60cfd4f6f39f11/src/Composer/Autoload/ClassLoader.php
>
> [2] https://github.com/composer/composer/blob/b6826f352390b4c952be8fd75d60cfd4f6f39f11/src/Composer/Autoload/ClassLoader.php#L478-L481
>
> --
> Jordi Boggiano
> @seldaek - https://seld.be
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
Edit: wrong sending address, again. Sending for list, apologies for the dupe.
I don’t have a huge amount of interest in this, except to say: If someone wants to add a core
function to make Composer’s autoloader work faster, that’s fine and dandy, it doesn’t hurt to
provide the building blocks for common patterns. But pushing your own biases about non-Composer
class autoloading being “antiquated” or “deprecated” is a step too far.