Re: Module or Class Visibility, Season 2

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]