> On 3 Jul 2024, at 23:51, Matthew Weier O'Phinney <mweierophin...@gmail.com> > wrote: > > > > On Wed, Jul 3, 2024 at 9:50 AM Stephen Reay <php-li...@koalephant.com > <mailto:php-li...@koalephant.com>> wrote: >> >> >>> On 3 Jul 2024, at 21:07, Vincent de Lau <vinc...@delau.nl >>> <mailto:vinc...@delau.nl>> wrote: >>> >>> From: Stephen Reay <php-li...@koalephant.com >>> <mailto:php-li...@koalephant.com>> >>> Sent: Wednesday, July 3, 2024 1:17 PM >>> >>>> On 1 Jul 2024, at 23:33, Mike Schinkel <mailto:m...@newclarity.net >>>> <mailto:m...@newclarity.net>> wrote: >>>>> Autoloading runs userland code. This means it has the potential conflict >>>>> between different packages with different autoloaders >>> >>>> *Can* run userland code. It doesn't *have to*; FYI spl_autoload >>>> (https://www.php.net/manual/en/function.spl-autoload.php) has existed >>>> since php5.1 and works amazingly well. >>>> >>>> That "standards" like psr-whatever can't (read: choose not to) use it says >>>> more about people and maintaining their little fiefdoms than anything >>>> else. >>> >>> As a PHP-FIG Core Committee member, I find this characterisation of people >>> involved in the FIG offensive. My contribution, however big or small, is >>> intended to help the PHP community at large. >>> >> >> If you choose to be offended by my opinion, I can't really help that. > > No, but you also don't need to air your personal grievances on the mailing > list. If you don't like what FIG or any other entity in the PHP ecosystem is > doing, this is NOT the place to air that grievance. Internals is for > discussing changes to the runtime. Calling out entities like this here is > bound to alienate folks who want to work on the engine, and who are also > parts of those groups. >
I'm glad we're in agreement that this list is about the runtime and not about composer or FIG. I look forward to seeing a response from you as vivid as this one, the next time someone responds to a discussion about something like function autoloading with "X isn't really a problem because composer". > It also doesn't help your argument when you're stating things that are flat > out wrong as facts. You can absolutely use spl_autoload() alongside the PSR > recommendations or Composer; see more below Please re-read what I wrote, before making ironic statements about 'facts'. I never said you can't use them "along side" each other. I said that the PSR's are incapable of using the built-in functionality provided by spl_autoload. That is: you can't adhere to either PSR using the builtin autoloader alone. That you can use them along-side each other is *unrelated* to `spl_autoload`, it's a function of the stack created by `spl_autoload_register`. > . >> >>> To come back to spl_autoload: That function pre-dates namespaces and is >>> highly opinionated on how to organise code. All lower-case filenames, class >>> per-file, files in include_path, full namespace in path, you name it. If >>> that is what projects wanted at the time, or even now, PSR-0 and the >>> PHP-FIG would possibly not even exist. >>> >> >> It's less highly opinionated than either PSR, but that's my whole point: >> it's *someone else's opinion*, hence it's opposed by FIG. > > That's a gross mischaracterization. > > In point of fact, most frameworks that joined FIG in the beginning were > leveraging spl_autoload_register(), which provides a _stack_ of autoloaders > that each provide their own logic for how to map classes to where on the > filesystem they live. spl_autoload_register() came after spl_autoload(), and > was introduced *to add flexibility* to the language, as spl_autoload is > proscriptive and only allows a single approach to autoloading, and it wasn't > even one that was widely used at the time it was introduced. It's not about > _opinions_, it's about recognizing that different approaches might have > merit. (Some might give better performance, some might allow pulling items > out of a phar or tarball, etc.) > spl_autoload, spl_autoload_register, and spl_autoload_extensions were all added in php5.1 (compare https://3v4l.org/H60EG#v5.0.5 vs https://3v4l.org/H60EG#v5.1.0). Maybe you're thinking of __autoload, which had no default implementation before `spl_autoload` was added. > The configurable part for autoloading in the language is > spl_autoload_register(), full stop. spl_autoload is (and has been since inception) configurable via spl_autoload_extensions, and via the standard include path.
