Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124302
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)
In-Reply-To: <1BE6A849-A2A9-4E17-9C11-5099EF74F5C0@rwec.co.uk>
Date: Mon, 8 Jul 2024 23:24:59 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <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>
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
From: mike@newclarity.net (Mike Schinkel)

> On Jul 8, 2024, at 5:41 AM, Rowan Tommins [IMSoP] =
<imsop.php@rwec.co.uk> wrote:
> I agree. I wrote most of the below a couple of days ago, but I don't =
think it posted correctly, so apologies if some people see it twice:=20
>=20
> Autoloading is just a way to load files later, by the engine telling =
you when a class is first needed. PHP does not, and should not, make any =
assumptions about how files are laid out on disk; an autoloader doesn't =
actually need to load any files at all, and if it does, it uses the same =
include or require statements which have been in PHP for decades.

I think maybe you are replying to an earlier iteration by Michael Morris =
and have not seen the more recent iteration? =20

There he explored adding an additional function to named =
`spl_autoload_map()` where the difference from `spl_autoload_register()` =
is that while the latter uses procedural code to determine what should =
be loaded the former would use a declarative map to determine what =
should be loaded. Then Composer and/or other tools could/would generate =
that map for PHP.

With an `spl_autoload_map()` PHP would not need to make any assumptions =
about how files are laid out on disk. Instead, PHP would use a schema of =
a yet-to-be-determined data representation format to discover  =
declaratively where files needed to be laid out on disk.

> Likewise, installing packages and defining version schemes is a =
completely separate problem space that can probably be served by a few =
small tweaks to Composer once the language provides the underlying =
functionality.
>=20
> The core of the problem you seem to want to solve is this: if you have =
two files foo_1.php and foo_2.php, which both define a class \Acme\Foo, =
how do you load both of them, so that you end up with two differently =
named classes?=20

That is one (1) of the core problems, yes.

> In JS, that's easy, because functions and object constructors (and =
"classes") exist as objects you can pass around as variables, they don't =
need to know their own name. In PHP, everything is based on the idea =
that functions and classes are identified by name. You can rewrite the =
name in the class declaration, and in direct references to it, but what =
about code using ::class, or constructing a name and using "new $name", =
and so on? How will tools using static analysis or reflection handle the =
renaming - e.g. how does DI autowiring work if names are in some sense =
dynamic?

This is one of the unfortunate	aspects of PHP never makes types a =
first-class data type. But I digress.

> You've also got to work out what to do with transitive dependencies - =
if I "import 'foo_1.php' as MyFoo", but Foo in turn has "import =
'guzzle_2.php' as MyGuzzle", what namespace do all Guzzle's classes get =
rewritten into? What about dependencies that are specifically intended =
to bridge between packages, like PSR-7 RequestInterface?

Which is a direct result of the other problem you mentioned, i.e. IOW =
without attempting to address the prior problem this would not be a =
problem. #fwiw

> My advice: start with the assumption that something has already =
installed all the files you need into an arbitrary directory structure, =
and something is going to generate a bunch of statements to load them.

And this sentence is why I chose to reply to your message.  That =
assumption itself blocks the needs of user-managed apps.

(Did you happen to read my compare-and-contrast of user-managed vs. =
developer-managed apps from a few days ago?)

I feel it is likely those who have never worked professionally in PHP on =
user-managed apps like WordPress  =E2=80=94 which I assume describes you =
accurately? =E2=80=94 are probably just simply unaware of the problems =
that your assumptions cause for user-managed apps. And yes, some =
developers have no empathy for others who have different circumstances, =
but I honestly don't think you (Rowan) are in the category.=20

Developer-managed apps use a build tool to put all vendor code in a =
single hierarchical set of namespaces and then load needed code from =
there. But that really does not work for user-managed apps like =
WordPress or Drupal.  Or at least not as they exist today, and probably =
not even if they were rearchitected for the start.

What works for user-managed apps is that each `add-on` (`plugin` in =
WordPress, `module` in Drupal) is stored in its own self-contained =
directory containing its own vendor code =E2=80=94 where some of the =
vendor code could easily be duplicated in another add-on =E2=80=94 and =
then the user-managed apps itself manages loading of all add-ons itself =
without a PSR-4 autoloader. As it exists, there are no standard for how =
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.=20

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. But making the assumption that "something has =
already installed all the files you need into an arbitrary directory =
structure" is not sufficient for the problems Michael Morris and I have =
been trying to address.

An autoloader map schema that has enough information for PHP to =
understand how to manage the conflicting names, and for the user-managed =
apps and Composer to be able to tell PHP what names are conflicting is =
in fact a solid way forward.

-Mike