Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127441
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 24 May 2025 15:11:57 +0200
To: internals@lists.php.net
Message-ID: <2adbff61-5e11-4d39-ab5c-d7950a4550a6@app.fastmail.com>
In-Reply-To: <10D95B6E-094B-4EAE-A18A-AF6B795CB352@rwec.co.uk>
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>
 <78641D8B-AF1D-4912-920A-D75A37C32F05@rwec.co.uk>
 <CAEUnE0dVyQ9NQonEBU6wkKM+WsyLXt68jAGYjsz270w_Fa8=Fw@mail.gmail.com>
 <CF275E74-F6AE-4357-8586-2FF17DC84FB5@rwec.co.uk>
 <CAEUnE0eR-0c=pDxgFrB4n60rGescZDVzOgb4uJbYK1aLvQE8=A@mail.gmail.com>
 <354cb888-97c4-4f8c-a0da-359d1e63c0f9@rwec.co.uk>
 <CAEUnE0dffEmFHV872btX5x_mbwmRmY1GCw+OPPrtr6sLD+u_zg@mail.gmail.com>
 <10D95B6E-094B-4EAE-A18A-AF6B795CB352@rwec.co.uk>
Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2
Content-Type: multipart/alternative;
 boundary=c6d792634d33400a9a2cfb128927d161
From: rob@bottled.codes ("Rob Landers")

--c6d792634d33400a9a2cfb128927d161
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sat, May 24, 2025, at 11:34, Rowan Tommins [IMSoP] wrote:
>=20
>=20
> Hi Michael,
>=20
> I'm going to skip over all the details about the autoloader for now, b=
ecause I think they're going deep into implementation details, and I wan=
t to focus on the same top-level design as my previous email.
>=20
>=20
> On 23 May 2025 02:27:41 BST, Michael Morris <tendoaki@gmail.com> wrote:
> >Bobs docs needs an older version of Monolog and is configured appropr=
iately
> >in its composer.json file, so ... v1 is prefixed to the
> >namespace declarations in Monolog\Logger and the file is included. The
> >engine aliases BobsDocs\Monolog\Logger to \v1\Monolog\Logger.
>=20
>=20
> If I'm following correctly, you suggest that we would end up with clas=
s names like this:
>=20
> \v1\Monolog\Logger
> \v2\Monolog\Logger
> \v5\Google\Client
> \v7\Google\Client
>=20
> It feels like there's a lot of complexity in the package manager here =
- it's got to keep track of which versions of each package are installed=
, what they depend on, and decide what prefixes need to be used where. Y=
ou also suggest that one version of each package is left with no prefix,=
 which adds even more complexity.
>=20
>=20
> >The Googl\ApiClient of BobDocs is again, up to the autoloader. Assumi=
ng it
> >too is different (since it's using an older Monolog)
>=20
> The biggest problem comes when this assumption doesn't hold. I actuall=
y chose these particular packages to illustrate this problem, then left =
it out of my previous message. It happens that the latest version of goo=
gle/apiclient supports both monolog/monolog 2.9 and 3.0, so it's possibl=
e to have:=20
>=20
> - AlicesCalendar wants to use google/apiclient 2.18 and monolog/monolo=
g 2.9
> - BobsDocs wants to use google/apiclient 2.18 and monolog/monolog 3.0
>=20
> If the package manager is adding prefixes to individual package versio=
ns, we will have one class called \v2_18\Google\Client containing our fa=
miliar "new Logger" line. AlicesCalendar will expect that line to create=
 a \v2_9\Monolog\Logger, but BobsDocs will expect it to create a \v3_0\M=
onolog\Logger. We can't please both of them without creating an extra co=
py of Google\Client with a different prefix.
>=20
> So the version of an individual package isn't enough to decide the pre=
fix, we need to know which *set* of packages it belongs to.=20
>=20
>=20
> My suggestion uses a much simpler rule to define the prefix: if it's l=
oaded "inside" AlicesCalendar, add the prefix "\AlicesCalendar\". All th=
e classes that are "inside" are completely sandboxed from the classes "o=
utside", without needing any interaction with a package manager.
>=20
> As far as I know, this is how existing userland solutions work, and I =
haven't yet spotted a reason why it needs to be any more complex than th=
at.
>=20
>=20
> Regards,
> Rowan Tommins
> [IMSoP]
>=20

My only concern is how this would be handled in the class tables. Right =
now, \AlicesCalendar\Monolog\Logger and \BobsDocs\Monolog\Logger would b=
e considered entirely different types -- as in, not compatible. So if Al=
icesCalendar returns a type that BobsDocs expects, they won't be able to=
 talk to each other.

So, this means we'd need a couple of different types of dependencies:
 1. "direct dependencies" that work in a containerized way
 2. "parent dependencies" that expect a parent to provide the dependency=
 so it can interoperate between packages
I assume that it will be up to a dependency resolver (either composer or=
 something else) will need to figure out which direct dependencies to "h=
oist" up and provide a compatible version between the two packages.

That then begs the question of whether this complication is needed at al=
l? I can understand why having a 'containerized' package system is usefu=
l (in the case of WordPress or plugins in general), but I'm wondering if=
 it is actually needed?

If we look at npm and yarn and how they handle this in the Javascript sp=
ace, they basically install compatible packages when possible, and only =
'contain' them when it would introduce an incompatibility.

I have some ideas here, but I need some time to think on it; but I also =
want to point out the problem to see if anyone else has any ideas.

=E2=80=94 Rob
--c6d792634d33400a9a2cfb128927d161
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Sat, May =
24, 2025, at 11:34, Rowan Tommins [IMSoP] wrote:</div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div><br></div><div><br></div><div>Hi Michae=
l,</div><div><br></div><div>I'm going to skip over all the details about=
 the autoloader for now, because I think they're going deep into impleme=
ntation details, and I want to focus on the same top-level design as my =
previous email.</div><div><br></div><div><br></div><div>On 23 May 2025 0=
2:27:41 BST, Michael Morris &lt;<a href=3D"mailto:tendoaki@gmail.com">te=
ndoaki@gmail.com</a>&gt; wrote:</div><div>&gt;Bobs docs needs an older v=
ersion of Monolog and is configured appropriately</div><div>&gt;in its c=
omposer.json file, so ... v1 is prefixed to the</div><div>&gt;namespace =
declarations in Monolog\Logger and the file is included. The</div><div>&=
gt;engine aliases BobsDocs\Monolog\Logger to \v1\Monolog\Logger.</div><d=
iv><br></div><div><br></div><div>If I'm following correctly, you suggest=
 that we would end up with class names like this:</div><div><br></div><d=
iv>\v1\Monolog\Logger</div><div>\v2\Monolog\Logger</div><div>\v5\Google\=
Client</div><div>\v7\Google\Client</div><div><br></div><div>It feels lik=
e there's a lot of complexity in the package manager here - it's got to =
keep track of which versions of each package are installed, what they de=
pend on, and decide what prefixes need to be used where. You also sugges=
t that one version of each package is left with no prefix, which adds ev=
en more complexity.</div><div><br></div><div><br></div><div>&gt;The Goog=
l\ApiClient of BobDocs is again, up to the autoloader. Assuming it</div>=
<div>&gt;too is different (since it's using an older Monolog)</div><div>=
<br></div><div>The biggest problem comes when this assumption doesn't ho=
ld. I actually chose these particular packages to illustrate this proble=
m, then left it out of my previous message. It happens that the latest v=
ersion of google/apiclient supports both monolog/monolog 2.9 and 3.0, so=
 it's possible to have:&nbsp;</div><div><br></div><div>- AlicesCalendar =
wants to use google/apiclient 2.18 and monolog/monolog 2.9</div><div>- B=
obsDocs wants to use google/apiclient 2.18 and monolog/monolog 3.0</div>=
<div><br></div><div>If the package manager is adding prefixes to individ=
ual package versions, we will have one class called \v2_18\Google\Client=
 containing our familiar "new Logger" line. AlicesCalendar will expect t=
hat line to create a \v2_9\Monolog\Logger, but BobsDocs will expect it t=
o create a \v3_0\Monolog\Logger. We can't please both of them without cr=
eating an extra copy of Google\Client with a different prefix.</div><div=
><br></div><div>So the version of an individual package isn't enough to =
decide the prefix, we need to know which *set* of packages it belongs to=
.&nbsp;</div><div><br></div><div><br></div><div>My suggestion uses a muc=
h simpler rule to define the prefix: if it's loaded "inside" AlicesCalen=
dar, add the prefix "\AlicesCalendar\". All the classes that are "inside=
" are completely sandboxed from the classes "outside", without needing a=
ny interaction with a package manager.</div><div><br></div><div>As far a=
s I know, this is how existing userland solutions work, and I haven't ye=
t spotted a reason why it needs to be any more complex than that.</div><=
div><br></div><div><br></div><div>Regards,</div><div>Rowan Tommins</div>=
<div>[IMSoP]</div><div><br></div></blockquote><div><br></div><div>My onl=
y concern is how this would be handled in the class tables. Right now, \=
AlicesCalendar\Monolog\Logger and \BobsDocs\Monolog\Logger would be cons=
idered entirely different types -- as in, not compatible. So if AlicesCa=
lendar returns a type that BobsDocs expects, they won't be able to talk =
to each other.</div><div><br></div><div>So, this means we'd need a coupl=
e of different types of dependencies:<br></div><ol><li>"direct dependenc=
ies" that work in a containerized way</li><li>"parent dependencies" that=
 expect a parent to provide the dependency so it can interoperate betwee=
n packages</li></ol><div>I assume that it will be up to a dependency res=
olver (either composer or something else) will need to figure out which =
direct dependencies to "hoist" up and provide a compatible version betwe=
en the two packages.</div><div><br></div><div>That then begs the questio=
n of whether this complication is needed at all? I can understand why ha=
ving a 'containerized' package system is useful (in the case of WordPres=
s or plugins in general), but I'm wondering if it is actually needed?</d=
iv><div><br></div><div>If we look at npm and yarn and how they handle th=
is in the Javascript space, they basically install compatible packages w=
hen possible, and only 'contain' them when it would introduce an incompa=
tibility.</div><div><br></div><div>I have some ideas here, but I need so=
me time to think on it; but I also want to point out the problem to see =
if anyone else has any ideas.</div><div><br></div><div id=3D"sig12122915=
2">=E2=80=94 Rob</div></body></html>
--c6d792634d33400a9a2cfb128927d161--