On Wed, Jul 3, 2024 at 9:50 AM Stephen Reay <php-li...@koalephant.com> wrote:
> > > On 3 Jul 2024, at 21:07, Vincent de Lau <vinc...@delau.nl> wrote: > > From: Stephen Reay <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> 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. 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. > > 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.) PSR-0 was created because a large number of projects were writing their own autoloaders that were doing similar things, and most of them were doing things _differently_ than spl_autoload() due to limitations of that approach, and all were using spl_autoload_register(). Creating a standard approach allowed users of these projects to use a single autoloader to load code from each within their application, which helped improve performance and reduced autoloading conflicts. PSR-4 extended the concept, while keeping some of the core ideas in place. And, again, YOU DO NOT NEED TO FOLLOW either one. Why? Because Composer uses spl_autoload_register() internally, and enables multiple autoloading approaches (PSR-0, PSR-4, classmap, file, etc.) out of the box. And if you don't want to use those for your own code... you can add another autoloader to the stack using spl_autoload_register(). You can even add your own _before_ invoking the Composer autoloader to ensure it gets precedence. Composer's then becomes primarily a tool for loading the third-party code your application depends on. > > Neither of which is the point I was making - someone claimed that > autoloaders are implicitly userland code. The point is they don't *have* to > be, and there is a perfectly useable one built in to the SPL extension; if > it's "too opinionated" (or the opinions are ones you don't like), it's > hardly the most in-depth of functions, and it already *has* configurable > parts, so adding in more control shouldn't exactly require a rocket > scientist to add, for example, the ability to use the original case of the > class name. > > The configurable part for autoloading in the language is spl_autoload_register(), full stop. And this _does_ require userland code. Yes, you can register spl_autoload() with it, and this is part of the engine, but that's the only language-level autoloader at this time. I'd argue we shouldn't add any more to the engine; the stack approach of spl_autoload_register() ensures we can reduce engine complexity and maintenance by offloading it to something that can evolve at a faster pace than the language. ----- I'm following the packaging threads closely, and the one thing I've failed to see a solid argument for is _what problems_ the current approach of using namespaced code doesn't address. I can definitely see a need for marking things as package private (i.e., not part of the publicly consumable API), but that also feels like something we could address in other ways. I know Larry has asked this same question before, and it's really what I want to see answered, because packages might be the solution, but there may be other approaches we could take that also accomplish those goals. -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him
