Re: Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)

> On 3 Jul 2024, at 23:51, Matthew Weier O'Phinney <mweierophinney@gmail.com> wrote: > > > > On Wed, Jul 3, 2024 at 9:50 AM Stephen Reay <php-lists@koalephant.com > <mailto:php-lists@koalephant.com>> wrote: >> >> >>> On 3 Jul 2024, at 21:07, Vincent de Lau <vincent@delau.nl >>> <mailto:vincent@delau.nl>> wrote: >>> >>> From: Stephen Reay <php-lists@koalephant.com >>> <mailto:php-lists@koalephant.com>> >>> Sent: Wednesday, July 3, 2024 1:17 PM >>> >>>> On 1 Jul 2024, at 23:33, Mike Schinkel >>>> <mailto:mike@newclarity.net >>>> <mailto:mike@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.