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. Right now,
> >\AlicesCalendar\Monolog\Logger and \BobsDocs\Monolog\Logger would 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.
>
> Once again, I'd like to use the Linux Container analogy: a process in one
> container never communicates directly with a process in another container.
> The process "thinks" it's running as normal, but is actually isolated inside
> 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.
>
>
>
> >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.
>
> I see this as the responsibility of each "container": if AlicesCalendar 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 PHP engine then
> knows to leave that interface name without a prefix. Any other class -
> whether it's written by Alice or installed by Composer - exists inside the
> sandbox, and gets a prefix.
>
> Importantly, all of this should happen on the *PHP symbol* level (classes,
> interfaces, functions); the sandboxing mechanism doesn't need to know about
> package managers - just as Docker, Kunernetes, etc, don't know about APT /
> Yum / whatever Apine calls it.
>
> Rowan Tommins
> [IMSoP]
>
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’t
required to function but may offer additional functionality if installed. 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 classes,
it should be possible to identify if a dependency/class is able to be used
outside the package during compilation. So, I don’t think 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 dependency.
Thus we would know that the current module would need to export the direct
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’s
point of view, they would use it like normal.
So, you could imagine a generated package manifest might look something like
this:
{
"rootNamespace": "OfficeSuite"
"dependencies": {
"AlicesCalendar": "^1.0.0",
"BobsDocs": "^0.1.0"
},
"exports": {
"dependencies": ["AlicesCalendar"],
"functions": ["OfficeSuite\doSomething"],
"classes": []
}
}
A package manager (IDE, or even a human) could then surmise what packages they
need to be shared between modules. It would also know that BobsDocs is entirely
private to the module, so it doesn’t need to be compatible with any other
module using BobsDocs.
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 classes. In other words, I’m
99% sure we can infer exported dependencies without requiring a human to
manually do the work; what that actually looks like in practice is still very
much in the air. So, please don’t take the above as an actual proposal, but as
inspiration.
— Rob
