On Fri, Apr 21, 2023, at 9:02 AM, Rowan Tommins wrote: > Hi Marco! > > First of all, please do stick around, and keep learning and being > curious. Sometimes out of the box thinking does get somewhere. > > That said, a lot of what you've written here is actually what already > happens, and the problems are elsewhere. > > > On 21/04/2023 04:54, Deleu wrote: > >> 1- Use include/require >> 2- Custom Autoloading (not for functions but bear with me) >> 3- Use Composer/PSR-4 > > > The first thing to note is that these aren't *options*, they're *layers* > on top of each other: to load some code from a file, you use > include/require; to load some code *on demand*, you write an autoload > function, which uses include/require; to let *someone else* write that > function, you lay your files out according to PSR-4 and use Composer, > which writes the autoload function, which uses include/require.
To piggyback on this point and go deeper into the "Composer/PSR-4" part: PSR-4 (and PSR-0 before it) are just standard rule for mapping a class name to a file. The intent is that an arbitrary autoloader written by anyone can then "find" classes from any package. PSR-0 came out in 2009. Composer came out in ~2012. It actually has four different loading mechanisms: PSR-0, PSR-4, "one big lookup map", and "files". PSR-0 and PSR-4 use those specs' class-name-to-file-name translation rules to look up a file on the fly. The "one big lookup map" scans the entire code base at dump time and builds up a big table of where every class-like is. Whether it conforms to PSR-4 or not is irrelevant. Then at runtime it just does an array lookup. I've many times run into the "fun" situation where a class was not properly named per PSR-4, but because the autoloader was set to auto-dump always, it never caused an issue as the built-map still worked! (Until it didn't, of course, because the lookup table is a cache that can get out of sync and give you no helpful error messages about it. I've lost much time this way.) And the "files" approach just greedily includes those files as soon as Composer initializes, and lets PHP take it from there. It's not even using an "autoloader" at all. (Fun fact: In Drupal 7, in the pre-PSR days, we built our own autoloader that worked on a "register and scan" model and stored a lookup table in the database. It... was not the best code I've ever written, but it did work for many years, and it's still running in the millions of Drupal 7 sites that still exist. For Drupal 8 we, thankfully, switched to Composer as the autoloader.) I've long felt that the advent of universal opcache usage and preloading (although few people use the latter, sadly) means that leveraging "files" should be a lot more popular than it is. That's what I do for my functional code (in Crell/fp); I just "files" include everything (which is admittedly not much) and move on with life. PHP is a lot faster at this than it once was. It's also why I'm only kind of luke warm on function autoloading. I'm not against it, but I don't see it as the blocker to more functional code that it once was. And as noted, how the heck do you then organize your functions so they're autoloadable? One per file is silly. So now we need to build some kind of map, and... we're back to the "one big lookkup map" approach, or something. I think there's still a lot of cultural aversion to front-loading code from the days when it was a lot more costly. PSR-4 is very good for what it is, but it's not the final word on code organization. It doesn't have to be treated that way, and that's a change that requires no core code changes. If we actually got working shared typedefs in the language, TBH I'd probably recommend people put all of their package's defs in a single file, "file" load it with Composer, and move on. Don't even bring PSR-4 into the picture. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
