Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127407
Feedback-ID: id5114917:Fastmail
Date: Tue, 20 May 2025 23:18:31 +0100
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2
User-Agent: K-9 Mail for Android
In-Reply-To: <CAEUnE0dxRwjhKC64XHWkF3bNRLgjkgSJ9oMajRPfwLoDWy3x-g@mail.gmail.com>
References: <CADK1yXKg1xpneLs3vJ=nUAAGaVuBhqkEMgbBVaYfcBfQL2vkDg@mail.gmail.com> <3ae9a6ea-f135-472b-b2bf-e6cd6ebad299@app.fastmail.com> <CAEUnE0d8QADSYv+OJMEceN4hdJNcNy=-GLvW-ZoNqoi6_2Lhxw@mail.gmail.com> <9A26F72B-D0EF-414F-B193-BED3CAB26A0B@rwec.co.uk> <9f6a0d6e-27c3-4f77-aed6-e55147442b6f@app.fastmail.com> <B46C391D-2248-4E54-BFBE-2195FFB6A2A5@rwec.co.uk> <ca5c49c9-948a-48f0-8b94-86fea583fbc4@app.fastmail.com> <673fd2db-b07f-439b-a4f2-e9519108d159@app.fastmail.com> <CAEUnE0dxRwjhKC64XHWkF3bNRLgjkgSJ9oMajRPfwLoDWy3x-g@mail.gmail.com>
Message-ID: <78641D8B-AF1D-4912-920A-D75A37C32F05@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 20 May 2025 15:04:49 BST, Michael Morris <tendoaki@gmail=2Ecom> wrote:
>The Problem: Interoperability=2E
>
>That's really it=2E  Scenario
>Alice provides whatchamacallit A that depends on other whatchamacallit D =
to
>work=2E
>Bob provides whatchamacallit B that also depends on D=2E
>Charles is using A and B=2E
>D gets updated with a new incompatible API to its prior version=2E
>Alice publishes an update which includes a security fix=2E
>Bob retired=2E
>Charles, who can't program, can't update to Alice's latest code=2E His si=
te
>eventually gets pwned=2E

Let me correct something here=2E The whole reason I was bringing in the di=
stinction between "module" and "container" is that B and C are one kind of =
thing, but D is a *different* kind of thing=2E=20

D is something like Guzzle=2E There is zero motivation for Guzzle to be re=
written in a way that forces its dependencies to be isolated=2E It depends =
on packages like "psr/http-client" whose *entire purpose* is to define inte=
rfaces that multiple packages agree on=2E

A, meanwhile, isn't a thing at all; it's just any old PHP code - in your e=
xample, the whole spaghetti of WordPress core=2E

B and C are the only "whatchamacallits" - they are, in your example, WordP=
ress plugins=2E They are the thing you want a boundary around, the black bo=
x you want conflicting names to be hidden by=2E



>Suppose we have a whatchamacallit that declares its namespace as a new ro=
ot
>independent of / =2E  If a file inclusion happens in this namespace, this
>namespace prepends everything in the included file=2E So if I do a file
>include in the \MyPlugin namespace and that file declares its namespace a=
s
>Twig, it will become \MyPlugin\Twig=2E

What does it mean, exactly, for a file inclusion to "happen in a namespace=
"? Bear in mind, most of the files we want to load, whether explicitly or v=
ia an autoloader, are not requests from A (the WordPress plugin) directly t=
o D (Guzzle); they are references between files inside D, or in further dep=
endencies that A has no idea about at all=2E

What PHP needs to track, somehow, is that a whole bunch of code is "inside=
" something, or "coloured by" something, in a way that is completely recurs=
ive=2E



>That works, but direct file include is no longer the PHP norm though=2E
>Autoloading is=2E So we need to tell the Autoloader that we want a file p=
ath
>returned - do NOT require the file yourself in your namespace=2E

This for me is a non-starter:  the existing packages which you want to mak=
e use of have little or no motivation to adapt to this new system=2E

Again, think about Linux containers: applications don't get a message sayi=
ng "you're running in a container, please use different file I/O convention=
s"; they *think* they are accessing the root filesystem, and the host *sile=
ntly* rewrites the access to be somewhere in the middle of a larger tree=2E

I think the way it would need to work would be some global state inside th=
e compiler, so that regardless of how the code ended up being loaded, an ex=
tra transform was included in the compilation pipeline to attempt to rewrit=
e all definitions, and all references to those definitions=2E

(I say "attempt", because even with all this built into the compiler, PHP'=
s highly dynamic nature means there would be code patterns that the rewrite=
r would not see; the whole thing would come with a bunch of caveats=2E)


>The above I think would more or less work, but it would lead to massive
>code duplication as Whatchamacallit A and B now have their own D's at \A\=
D
>and \B\D (assuming namespaces match whatchamacallit names)=2E

I don't think this is a problem that can or should be solved=2E

Imagine A and B both use the same version of E, but different versions of =
D; and E references D=2E If we try to de-duplicate, we load one copy of E, =
but when called from A it needs to reference \A\D and when called from B it=
 needs to reference \B\D=2E Clearly, that's not going to work, so we're for=
ced to define a separate \A\E and \B\E=2E

Note that this is completely different from any de-duplication of files on=
 disk that a package manager might perform=2E It's a bit like the same C so=
urce file being compiled into two different object files with different #de=
fines in effect=2E


I'm still not convinced that all this complexity actually leaves you bette=
r off than building a Composer plugin that automatically applies the rewrit=
ing to a whole directory at source code level=2E

Rowan Tommins
[IMSoP]