Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124304
Feedback-ID: id5114917:Fastmail
Date: Tue, 09 Jul 2024 08:10:16 +0100
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)
User-Agent: K-9 Mail for Android
In-Reply-To: <B814CAB0-50DA-4EB3-97EE-72542EFCD184@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> <CAMrTa2EvD3qcTL5SoXwAJ6kT5NTu0QLSQjjJRa0z-esUMVxj6w@mail.gmail.com> <1BE6A849-A2A9-4E17-9C11-5099EF74F5C0@rwec.co.uk> <B814CAB0-50DA-4EB3-97EE-72542EFCD184@newclarity.net>
Message-ID: <98D6A4CA-EBFC-44CC-9DD4-14C0D7AF0AC9@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 9 July 2024 04:24:59 BST, Mike Schinkel <mike@newclarity=2Enet> wrote:
>I think maybe you are replying to an earlier iteration by Michael Morris =
and have not seen the more recent iteration? =20

I wrote the message a few days ago, but it didn't post; but the more recen=
t discussion still seems to be focussing on things that can be solved in us=
erland, rather than the fundamentally hard parts=2E


>There he explored adding an additional function to named `spl_autoload_ma=
p()` where the difference from `spl_autoload_register()` is that while the =
latter uses procedural code to determine what should be loaded the former w=
ould use a declarative map to determine what should be loaded=2E Then Compo=
ser and/or other tools could/would generate that map for PHP=2E

You can implement this in userland, right now=2E The point of calling proc=
edural code for the autoloader is that it can do anything it likes to defin=
e the symbol - it can look it up in a table of directories, it can load som=
e code from a database and eval() it, whatever you need=2E In fact, Compose=
r already does implement such a file map, that's what its "optimize autoloa=
der" option creates=2E

What you can't easily do is run different code depending on where the symb=
ol is used - but since the autoloader is only called once per symbol, doing=
 so wouldn't make much sense=2E



>> My advice: start with the assumption that something has already install=
ed all the files you need into an arbitrary directory structure, and someth=
ing is going to generate a bunch of statements to load them=2E
>
[=2E=2E=2E]
>What works for user-managed apps is that each `add-on` (`plugin` in WordP=
ress, `module` in Drupal) is stored in its own self-contained directory con=
taining its own vendor code

Note that I said "arbitrary directory structure", not "PSR-4/Composer dire=
ctory structure"; the files are on disk somewhere=2E PHP didn't put them th=
ere, some application did=2E The application knows where they are, and need=
s to tell PHP somehow=2E


> =E2=80=94 where some of the vendor code could easily be duplicated in an=
other add-on

This is the hard part I was suggesting you focus on=2E


> and then the user-managed apps itself manages loading of all add-ons its=
elf without a PSR-4 autoloader=2E As it exists, there are no standard for h=
ow add-on filenames and directory structures much be named nor how they are=
 to load their dependencies so it is impossible for WordPress or Drupal to =
take on that role using PSR-4 for them=2E

WordPress doesn't need PHP Internals, or even PHP-FIG, to define how plugi=
ns should be laid out on disk, and to write an autoloader for whatever they=
 come up with=2E


>Michael Morris' idea to add an `spl_autoload_map()` function would allow =
addressing the needs of user-managed apps that treat each add-on as a self-=
contained entity=2E But making the assumption that "something has already i=
nstalled all the files you need into an arbitrary directory structure" is n=
ot sufficient for the problems Michael Morris and I have been trying to add=
ress=2E

It doesn't need to solve all the needs of the application, it needs to sol=
ve the parts we don't already have=2E WordPress already knows how to downlo=
ad files to disk; it could trivially design a system for plugin authors to =
lay out their own classes in some agreed layout and write an autoloader usi=
ng the functionality that's been around since PHP 5=2E3=2E

The part it can't do is load two classes with the same fully-qualified nam=
e, because the language has no base functionality to build that on=2E Desig=
ning configuration files is a complete waste of time until you've designed =
that base functionality: when you load two classes with the same fully-qual=
ified name, what exactly do you want the engine to do? What will need to ch=
ange in the core of the language to make that possible?

Regards,
Rowan Tommins
[IMSoP]