> I don't really see the advantage of having "spl_autoload_psr4_enable" and > "spl_autoload_psr4_enabled" functions: since there's a new > "spl_autoload_psr4_register" function, it means the feature should be > enabled by default, but registering PSR-4 namespaces is still opt-in. > Composer's autoloader might evolve in time to use it, but it can internally > detect PHP's version and dump the same autoloader as today for current PHP > versions, and dump a "new" autoloader for PHP versions using built-in PSR-4 > autoloading. > I felt the need for a flag function because there may be a scenario where an autoloader may need to toggle built in psr4 autoloading, I always air on the side of verbosity over simplicity.
If you're using Composer, built-in PSR-4 autoloading is a good start, but > in the end it won't be enough: Composer still supports PSR-0, and supports > custom files and classmaps. Adding built-in support for PSR-0 isn't > necessarily useful (since it's supposed to have been deprecated for a long > time now), but custom classmaps could be interesting. A function > "spl_register_classmap_autoload(array $classmap, bool $prepend = false)" > function (or for single registrations with "string $class, string > $filepath" instead of an array, whatever) could also be used by Composer in > the future. > This is the same reason why i felt supporting PSR-0 wasnt needed. PSR-0 is superseded by PSR-4 for years now and while is isnt deprecated yet, it is widely understood that it shouldn't be used over PSR-4. PSR-0 was the starting point of autoloading and is a bad solution to a good problem, PSR-4 was the good solution to a good problem. > And by extrapolating, we can have more functions to replace the process > Composer goes on when generating a classmap with the "-o / --optimize" > option in the "dump-autoload" command and make the first run of a process > handling generate the classmap for certain registered psr4 namespaces and > put them in cache (opcache, memcache, apcu...) (something like > "generate_psr4_classmap(string $nsPrefix)", or with the cache backend's > name like "opcache_generate_classmap_from_psr4(string $nsPrefix)" ), so > that further executions "just" fetch this classmap cache from memory, thus > enhancing built-in PSR-4 autoloading (just like Composer's, but built-in, > and classmap stored natively in memory instead of the generated classmap > file being stored in opcache and having to be re-run). Benchmarks would be > needed to check if built-in classmap would be better than Composer's (so it > implies a cache backend to check if re-running the generated classmap is > slower or not than a built-in memory hashmap of classes and files), but > it's feasible. In my mind that would all be handled by the engine. You wouldn't need to call `generate_*` or `opcache_*` functions as the classmap should be stored in direct memory in a structured layout for optimal use. I would think that the autoloader would have minimal AST, the autoloader would be a blackbox to opcache. A class is called -> its not loaded -> it is registered -> it is now loaded huzzah. WDYT? Should an extrapolation of your suggestion make it to the core too? > (I personally think it should, either with this first RFC or with further > RFCs once this one is accepted) Thats why this is a discussion, get a grasp of ideas, solutions and gauge support for the proposal.
