Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124347
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-568-g843fbadbe-fm-20240701.003-g843fbadb
Precedence: bulk
MIME-Version: 1.0
Message-ID: <4bf9a581-41a2-41d6-9adc-a5732818d110@app.fastmail.com>
In-Reply-To: <EA1B29C9-2EDB-4449-8BC1-5ED09D29A336@newclarity.net>
References: <09559430-4477-4516-8D78-6F4071E1AA6C@newclarity.net>
 <0182F3D6-F464-477F-9029-A2D0A8B50C71@koalephant.com>
 <GV1PR01MB10526D0B220ED0AC9D1C17473C2DD2@GV1PR01MB10526.eurprd01.prod.exchangelabs.com>
 <1AFD7AAE-8BEA-460D-88A8-15BB3D30A775@koalephant.com>
 <CAJp_myXHSHD6+76gyOs=d+cfVgwCmpuhKMtYcVBM6b-i3Bf0WQ@mail.gmail.com>
 <CAEUnE0dObGkb+jUZrVhNRg0JHaM5Kt9d93k3p_0D=jX7kxmYAg@mail.gmail.com>
 <e42cd46b-d98b-4567-a854-03ca54d4dbcf@app.fastmail.com>
 <CAEUnE0cQA-QrmDmAjpBm=sXkE58Y4ODbNwPYY=QBJV46Q8nR9g@mail.gmail.com>
 <CAEUnE0eEjsBXmz8AEVG1SKE=i08-9dit1ze1K0mWrdyQt4okqQ@mail.gmail.com>
 <7B633CC7-C768-4852-A4D0-B252A04F7DE1@newclarity.net>
 <CAEUnE0fFfggyvtNGMytWATG7xUrwfjtXp5F0Sk9PvXo-1Rf+_g@mail.gmail.com>
 <0E11F373-99DC-496E-9BBC-2F8688B9F66A@newclarity.net>
 <CAEUnE0fMGzYimJr71VSFr44FQPBzszfd7FbScfwYx794GZMsrQ@mail.gmail.com>
 <4F720A7A-B7DD-4B31-B0C9-6907419B53A5@newclarity.net>
 <CAEUnE0cf2ekFTsQphH8GjzZ4Yds2DXwxS_DT37UZ4reMHg=D+Q@mail.gmail.com>
 <D412D0D3-AD94-4B06-A302-AC7215271367@newclarity.net>
 <7b40e925-d642-4cf4-83f8-f903a9964362@app.fastmail.com>
 <EA1B29C9-2EDB-4449-8BC1-5ED09D29A336@newclarity.net>
Date: Wed, 10 Jul 2024 09:07:37 -0500
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Jul 10, 2024, at 1:38 AM, Mike Schinkel wrote:

>> In fact, if you use an optimized/dumped autoloader, then Composer sim=
ply builds an internal giant lookup table of what class maps to what fil=
e.  PSR-4 is then *completely irrelevant* at runtime.  It's already one =
giant O(1) lookup map.  That can be done *today*.  That *is* done today.
>
> Yes, it can be done today. It *is* done today.  By. Developer. Managed=
. Apps.


> Already done.  I explained how an `spl_autoload_map()` would do exactl=
y=20
> that above.
>
>> When you have a proven that it's even possible to have multiple local=
 symbol tables, we can talk.  Until then, please spare us.
>
> My one useful takeaway from your email =E2=80=94 except that I already=
 knew=20
> that =E2=80=94 was the need to figure out how PHP can handle multiple =
symbol=20
> tables.  Beyond that, your take your own advice and spare us (me) from=20
> your contempt and condescension as they are not good looks on anyone.

I find it amusing that several of your responses to me saying "you could=
 do this stupid thing but no one does that" is "WordPress does that thin=
g."  I make no comment other than to observe it.

But let me understand: In a thread started by Michael Morris where he ex=
plicitly said the most important thing for him is multi-version loading,=
 you're going to insist you're talking only about moving Composer's clas=
smap logic into core, and nothing about multi-version loading.

If that's the case, then please be polite to Michael Morris and get out =
of his thread.

Also, be aware that classmap-in-core was already discussed 3 years ago a=
nd went nowhere.

https://wiki.php.net/rfc/autoload_classmap
https://externals.io/message/113545

Largely because, as Sara said then, and Rowan just said on this thread, =
it can be done better in user-space and is already done better in user-s=
pace... by Composer.

https://externals.io/message/113569

You even commented in that thread:

https://externals.io/message/113554

So it's not a new idea, it's an idea that's already been greeted with a =
general "meh".

Yes, most "developer managed apps" use Composer today to side-step the "=
bajillion autoloaders" problem.  It's a solved problem.

Nothing precludes Wordpress from doing the same.  I admittedly have not =
looked at WP's core in a very long time, but I would be absolutely shock=
ed if it wasn't pretty straightforward to build code into WP core that l=
ooks at the source directories of all plugins, finds the classes there, =
and builds a big index (stored in a cache directory or the database) tha=
t it can use in one single autoloader registered by WP itself.  I know t=
hat can be done, because that's exactly how Drupal 7's autoloader worked=
.  I know, because I wrote it.  In 2008.  (It was later modified by othe=
rs, but the initial version was mine.)

That would work even with WP's "download code and drop it on disk" model=
.  That has been possible since PHP 5.2 at least, when I wrote exactly t=
hat for Drupal.  It wasn't even that hard.  Literally any "user managed =
app" could do the same.

Why hasn't WP core done that in order to make life easier for plugin dev=
elopers and avoid registering 50 separate autoloaders?  I dunno, you sho=
uld ask Matt Mullenweg.  We have nothing to do with it.

--Larry Garfield