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

Reply via email to