Re: Versioned Packagers (Iteration IV)

From: Date: Wed, 10 Jul 2024 12:33:35 +0000
Subject: Re: Versioned Packagers (Iteration IV)
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On Wed, 10 Jul 2024, at 07:38, Mike Schinkel wrote:
> The request is to add class maps with a PHP-standardized format into 
> PHP core so that when a library of code needs to register classes to be 
> autoloaded they can contribute to a cascading of class maps where ONE 
> internal function checks the single union of all class maps for a 
> mapped symbol before turning over control if no such symbol is found in 
> the map to the procedural autoloaders that are currently available. 
> That way *any* PHP code could register its own class map without having 
> to get the core app to rearchitect itself to allow that to happen.

Everything you've just described is possible, today, with no changes to PHP core. And the
easiest way to implement it is to borrow the existing battle-tested implementation in Composer,
maybe tweaking it with plugins, and automating it with its PHP API rather than using its CLI
interface.

If you look at "vendor/composer/autoload_psr4.php" in a project where you've run
"composer install", you'll find a mapping of namespaces to directories; PSR-4 then
defines where individual classes are within each of those directories. If you tell Composer to dump
an optimized autoloader, it will instead create a mapping of individual class names to file paths.

So let's step back a second, and look at the pros and cons of implementing it in core:

Pros:
- Possibly a bit faster if the C code can be optimised
- "Blessed" by the PHP project, which makes it a standard of sorts
- No library code to copy or install into a project

Cons:
- Requires a minimum PHP version to run (a huge problem for WordPress, famous for its broad version
support)
- Improvements can only be accessed by updating PHP
- Breaking changes are nearly impossible, because users can't choose between major versions
within one version of PHP
- Limited ability to tweak for a particular project if the standard solution doesn't meet their
needs

Things that won't change:
- You still need a standard layout of files within each directory (e.g. PSR-4, or whatever layout
you prefer), or to run something that analyzes your code and generates a comprehensive class map
(i.e. does the same job as Composer's optimized autoload generator)
- The application still needs some central code to register those directory or file lists, e.g. when
you install a WordPress plugin, something has to load its configuration file
- PHP still won't be able to have two classes with the same name, because that's a
completely separate problem, unrelated to autoloading

Regards,
-- 
Rowan Tommins
[IMSoP]


Thread (128 messages)

« previous php.internals (#124343) next »