On Wed, Jul 3, 2024, at 18:51, Matthew Weier O'Phinney wrote: > > > 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
Hi Mathew! My main feedback to PSR’s is that they are fundamentally broken due to being outdated. The idea behind the standards is sound, but there are only a few PSRs that are applicable to today’s PHP. When I look at creating new libraries today, PSR’s are a good inspiration, but they probably shouldn’t be used in actual programs. Here’s a short list of outdated standards I’ve collected over the last couple of years: • 7 • 11 • 15 • 18 • 20 Most of these breakdown if you start dealing with fibers, various new scopes introduced by runtimes, new http standards, etc. Ergo, if you’ve run into these issues, you are likely inclined to stay as far away from PSR’s as reasonably possible and may have a negative view of them. However, for enterprise applications, PSR’s are a godsend. So they do have their uses, don’t get me wrong, but if you want to use technology newer than 2019-ish, you need to avoid them; and this is a large part of why I say PSR-XX isn’t a valid argument on this list. All that being said, I’ve also looked into contributing over there, but my time is solidly booked up at the moment. Even on this list, I mostly only participate on the train to/from work. — Rob
