> On 16 Mar 2021, at 20:07, Jordi Boggiano <j.boggi...@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
