On Fri, Apr 21, 2023 at 11:18 AM Larry Garfield <la...@garfieldtech.com> wrote:
> 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 > > Hey thanks for the reply. I just want to go an extra mile to make my points clearer. Please take no negative connotation from what I posted towards Composer, PSR-0, PSR-4 or such. I was merely describing things from an end-user perspective to bring everything I think about into context. My simplistic and naive view of things come from reading about typed callables, function autoloading and type aliases. My biggest question is still understanding what is fundamentally different between `class Bar` and `type Foo = Bar|Baz`. I understand that the current state of things in the PHP world, folks will likely hate declaring 1 type = 1 file to conform with PSR-4, but that has nothing to do with the engine - it's not good nor bad for the PHP engine and just extends on an extremely well defined existing principle of PHP symbols. The recursive resolution of function autoloading does explain a little bit why it has been controversial and a final decision has not come out of it yet, but even there it's just a matter of whether consensus can be achieved that a combination of PHP Engine + Community work can bring to a great final state and not every detail needs to be burdened on internals. At the end of the day I would love to declare a few functions on a single file, a few enums on another file, a few type aliases on another file and perhaps even a few intertwined/related small classes on the same file. PHP Autoloading functionality is 90% there and we would just need function autoloading, type aliases definition and PSR-X + Composer static symbol scanner (something that seems to already exist?) to make it a great developer experience. If you don't use Composer, nothing gets worse (except maybe function autoloading + performance), but if you use composer already, this can be a seamless transition and perhaps even bring more interest towards preloading. To maybe beat up more on function autoloading, if I understand correctly the current open proposal sidesteps the performance impact by making function autoloading a "separate autoloading filtered by type" kind of mechanism. If you upgrade from PHP 8.x to 8.x+1 with no code changes, your performance impact is zero. Your first performance impact arises when you register a function autoloading (making it opt-in) & then you can choose to opt-in by using a strategy that perhaps allows you to fade away the performance impact with the Composer Static Scanner dumping mechanism. I feel like this all sounds too good to be true/possible because if it were easy, it would maybe have been done by now. Even if we park function autoloading altogether (for its controversy) and focus just on type aliases, the question remains: Why is it not possible to make Type Alias the same way that Enum was recently introduced? -- Marco Deleu
