On Sat, May 24, 2025, at 4:18 PM, Rowan Tommins [IMSoP] wrote: >>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]
This is where I'm not clear. Why wouldn't it need a concept of package/module/thing? Even if we develop some way such that in Foo.php, loading the class \Beep\Boop\Narf pulls from /beep/boop/v1/Narf.php and loading it from Bar.php pulls the same class from /beep/boop/v2/Narf.php, and does something or other to keep the symbols separate... Narf itself is going to load \Beep\Boop\Poink at some point. So which one does it get? Or rather, there's now two Narfs. How do they know that the v1 version of Narf should get the v1 version of Poink and the v2 version should get the v2 version. If there was a package/module/cluster/thing concept, then it would be easy enough (at least in concept) to extend whatever translation logic exists to the rest of that package/module/cluster/thing. Without that, however, I don't know how that transitive class usage would be addressed. --Larry Garfield
