Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127451
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 25 May 2025 10:27:32 +0200
To: internals@lists.php.net
Message-ID: <d870c119-3203-425d-95e8-55f34ea16a4c@app.fastmail.com>
In-Reply-To: <79E7FA26-2F5A-470C-B1DF-12CC46A08FE5@rwec.co.uk>
References: 
 <CADK1yXKg1xpneLs3vJ=nUAAGaVuBhqkEMgbBVaYfcBfQL2vkDg@mail.gmail.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>
 <2adbff61-5e11-4d39-ab5c-d7950a4550a6@app.fastmail.com>
 <79E7FA26-2F5A-470C-B1DF-12CC46A08FE5@rwec.co.uk>
Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2
Content-Type: multipart/alternative;
 boundary=da6080eef648483cb00698cffd41726f
From: rob@bottled.codes ("Rob Landers")

--da6080eef648483cb00698cffd41726f
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sat, May 24, 2025, at 23:18, Rowan Tommins [IMSoP] wrote:
> On 24 May 2025 14:11:57 BST, Rob Landers <rob@bottled.codes> wrote:
> >My only concern is how this would be handled in the class tables. Rig=
ht now, \AlicesCalendar\Monolog\Logger and \BobsDocs\Monolog\Logger woul=
d be considered entirely different types -- as in, not compatible. So if=
 AlicesCalendar returns a type that BobsDocs expects, they won't be able=
 to talk to each other.
>=20
> Once again, I'd like to use the Linux Container analogy: a process in =
one container never communicates directly with a process in another cont=
ainer. The process "thinks" it's running as normal, but is actually isol=
ated inside a sandbox. The container then defines the inputs and outputs=
 it wants to open between that sandbox and the host, and something runni=
ng on the host can wire those up as necessary.
>=20
>=20
>=20
> >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=
 "hoist" up and provide a compatible version between the two packages.
>=20
> I see this as the responsibility of each "container": if AlicesCalenda=
r wants to use an un-sandboxed version of a PSR interface or a framework=
 component, it declares that to the "host" (e.g. WordPress core). The PH=
P engine then knows to leave that interface name without a prefix. Any o=
ther class - whether it's written by Alice or installed by Composer - ex=
ists inside the sandbox, and gets a prefix.
>=20
> Importantly, all of this should happen on the *PHP symbol* level (clas=
ses, interfaces, functions); the sandboxing mechanism doesn't need to kn=
ow about package managers - just as Docker, Kunernetes, etc, don't know =
about APT / Yum / whatever Apine calls it.
>=20
> Rowan Tommins
> [IMSoP]
>=20

Yes, that aligns with what I was thinking too, for the most part.

Here are my thoughts, but first some vocabulary:
- direct dependency: a package that is used by the current package
- exported dependency: a direct dependency that can be used outside the =
current package
- peer dependency: an indirect dependency on another package that isn=E2=
=80=99t required to function but may offer additional functionality if i=
nstalled. I have no idea how this would be defined or used yet.
- package: the physical artefact containing one or more modules.

Thinking back on several of my implementation explorations of nested cla=
sses, it should be possible to identify if a dependency/class is able to=
 be used outside the package during compilation. So, I don=E2=80=99t thi=
nk we need the user to explicitly state an exported dependency. In other=
 words (and making up some syntax):

use module AlicesCalendar;
use module BobsDocs;

// AlicesCalendar needs to be "exposed" outside the package
public function doSomething(\AlicesCalendar\Week $week) { /* do stuff */=
 }

// BobsDocs remains an internal-only dependency
private function otherSomething(\BobsDocs\Doc $doc) { /* do stuff */ }

When compiling, we will see a public function "exposing" a direct depend=
ency. Thus we would know that the current module would need to export th=
e direct dependency on AlicesCalendar. This would prevent the developer =
from having to keep track of all the dependencies that need to be export=
ed. From a developer=E2=80=99s point of view, they would use it like nor=
mal.

So, you could imagine a generated package manifest might look something =
like this:

{
  "rootNamespace": "OfficeSuite"
  "dependencies": {=20
    "AlicesCalendar": "^1.0.0",=20
    "BobsDocs": "^0.1.0"=20
  },
  "exports": {=20
    "dependencies": ["AlicesCalendar"],=20
    "functions": ["OfficeSuite\doSomething"],
    "classes": []
  }
}

A package manager (IDE, or even a human) could then surmise what package=
s they need to be shared between modules. It would also know that BobsDo=
cs is entirely private to the module, so it doesn=E2=80=99t need to be c=
ompatible with any other module using BobsDocs.

Anyway, this is a bit into the weeds, but I want to point out what is po=
ssible or not, based on my experience working on nested classes. In othe=
r words, I=E2=80=99m 99% sure we can infer exported dependencies without=
 requiring a human to manually do the work; what that actually looks lik=
e in practice is still very much in the air. So, please don=E2=80=99t ta=
ke the above as an actual proposal, but as inspiration.

=E2=80=94 Rob
--da6080eef648483cb00698cffd41726f
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 23:18, Rowan Tommins [IMSoP] wrote:</div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div>On 24 May 2025 14:11:57 BST, Rob Lander=
s &lt;<a href=3D"mailto:rob@bottled.codes">rob@bottled.codes</a>&gt; wro=
te:</div><div>&gt;My only concern is how this would be handled in the cl=
ass tables. Right now, \AlicesCalendar\Monolog\Logger and \BobsDocs\Mono=
log\Logger would be considered entirely different types -- as in, not co=
mpatible. So if AlicesCalendar returns a type that BobsDocs expects, the=
y won't be able to talk to each other.</div><div><br></div><div>Once aga=
in, I'd like to use the Linux Container analogy: a process in one contai=
ner never communicates directly with a process in another container. The=
 process "thinks" it's running as normal, but is actually isolated insid=
e a sandbox. The container then defines the inputs and outputs it wants =
to open between that sandbox and the host, and something running on the =
host can wire those up as necessary.</div><div><br></div><div><br></div>=
<div><br></div><div>&gt;I assume that it will be up to a dependency reso=
lver (either composer or something else) will need to figure out which d=
irect dependencies to "hoist" up and provide a compatible version betwee=
n the two packages.</div><div><br></div><div>I see this as the responsib=
ility of each "container": if AlicesCalendar wants to use an un-sandboxe=
d version of a PSR interface or a framework component, it declares that =
to the "host" (e.g. WordPress core). The PHP engine then knows to leave =
that interface name without a prefix. Any other class - whether it's wri=
tten by Alice or installed by Composer - exists inside the sandbox, and =
gets a prefix.</div><div><br></div><div>Importantly, all of this should =
happen on the *PHP symbol* level (classes, interfaces, functions); the s=
andboxing mechanism doesn't need to know about package managers - just a=
s Docker, Kunernetes, etc, don't know about APT / Yum / whatever Apine c=
alls it.</div><div><br></div><div>Rowan Tommins</div><div>[IMSoP]</div><=
div><br></div></blockquote><div><br></div><div>Yes, that aligns with wha=
t I was thinking too, for the most part.</div><div><br></div><div>Here a=
re my thoughts, but first some vocabulary:</div><div>- direct dependency=
: a package that is used by the current package</div><div>- exported dep=
endency: a direct dependency that can be used outside the current packag=
e</div><div>- peer dependency: an indirect dependency on another package=
 that isn=E2=80=99t required to function but may offer additional functi=
onality if installed. I have no idea how this would be defined or used y=
et.</div><div>- package: the physical artefact containing one or more mo=
dules.</div><div><br></div><div>Thinking back on several of my implement=
ation explorations of nested classes, it should be possible to identify =
if a dependency/class is able to be used outside the package during comp=
ilation. So, I don=E2=80=99t think we need the user to explicitly state =
an exported dependency. In other words (and making up some syntax):</div=
><div><br></div><div>use module AlicesCalendar;</div><div>use module Bob=
sDocs;</div><div><br></div><div>// AlicesCalendar needs to be "exposed" =
outside the package</div><div>public function doSomething(\AlicesCalenda=
r\Week $week) { /* do stuff */ }</div><div><br></div><div>// BobsDocs re=
mains an internal-only dependency</div><div>private function otherSometh=
ing(\BobsDocs\Doc $doc) { /* do stuff */ }</div><div><br></div><div>When=
 compiling, we will see a public function "exposing" a direct dependency=
. Thus we would know that the current module would need to export the di=
rect dependency on AlicesCalendar. This would prevent the developer from=
 having to keep track of all the dependencies that need to be exported. =
From a developer=E2=80=99s point of view, they would use it like normal.=
</div><div><br></div><div>So, you could imagine a generated package mani=
fest might look something like this:</div><div><br></div><div>{</div><di=
v>&nbsp; "rootNamespace": "OfficeSuite"</div><div>&nbsp; "dependencies":=
 { </div><div>&nbsp; &nbsp; "AlicesCalendar": "^1.0.0", </div><div>&nbsp=
; &nbsp; "BobsDocs": "^0.1.0" </div><div>&nbsp; },</div><div>&nbsp; "exp=
orts": { </div><div>&nbsp; &nbsp; "dependencies": ["AlicesCalendar"], </=
div><div>&nbsp; &nbsp; "functions": ["OfficeSuite\doSomething"],</div><d=
iv>&nbsp; &nbsp; "classes": []</div><div>&nbsp; }</div><div>}</div><div>=
<br></div><div>A package manager (IDE, or even a human) could then surmi=
se what packages they need to be shared between modules. It would also k=
now that BobsDocs is entirely private to the module, so it doesn=E2=80=99=
t need to be compatible with any other module using BobsDocs.</div><div>=
<br></div><div>Anyway, this is a bit into the weeds, but I want to point=
 out what is possible or not, based on my experience working on nested c=
lasses. In other words, I=E2=80=99m 99% sure we can infer exported depen=
dencies without requiring a human to manually do the work; what that act=
ually looks like in practice is still very much in the air. So, please d=
on=E2=80=99t take the above as an actual proposal, but as inspiration.</=
div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></=
html>
--da6080eef648483cb00698cffd41726f--