On 24 May 2025 14:11:57 BST, Rob Landers <[email protected]> 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]