On Sat, May 24, 2025, at 11:34, Rowan Tommins [IMSoP] wrote: > > > Hi Michael, > > I'm going to skip over all the details about the autoloader for now, because > I think they're going deep into implementation details, and I want to focus > on the same top-level design as my previous email. > > > On 23 May 2025 02:27:41 BST, Michael Morris <tendo...@gmail.com> wrote: > >Bobs docs needs an older version of Monolog and is configured appropriately > >in its composer.json file, so ... v1 is prefixed to the > >namespace declarations in Monolog\Logger and the file is included. The > >engine aliases BobsDocs\Monolog\Logger to \v1\Monolog\Logger. > > > If I'm following correctly, you suggest that we would end up with class names > like this: > > \v1\Monolog\Logger > \v2\Monolog\Logger > \v5\Google\Client > \v7\Google\Client > > It feels like there's a lot of complexity in the package manager here - it's > got to keep track of which versions of each package are installed, what they > depend on, and decide what prefixes need to be used where. You also suggest > that one version of each package is left with no prefix, which adds even more > complexity. > > > >The Googl\ApiClient of BobDocs is again, up to the autoloader. Assuming it > >too is different (since it's using an older Monolog) > > The biggest problem comes when this assumption doesn't hold. I actually chose > these particular packages to illustrate this problem, then left it out of my > previous message. It happens that the latest version of google/apiclient > supports both monolog/monolog 2.9 and 3.0, so it's possible to have: > > - AlicesCalendar wants to use google/apiclient 2.18 and monolog/monolog 2.9 > - BobsDocs wants to use google/apiclient 2.18 and monolog/monolog 3.0 > > If the package manager is adding prefixes to individual package versions, we > will have one class called \v2_18\Google\Client containing our familiar "new > Logger" line. AlicesCalendar will expect that line to create a > \v2_9\Monolog\Logger, but BobsDocs will expect it to create a > \v3_0\Monolog\Logger. We can't please both of them without creating an extra > copy of Google\Client with a different prefix. > > So the version of an individual package isn't enough to decide the prefix, we > need to know which *set* of packages it belongs to. > > > My suggestion uses a much simpler rule to define the prefix: if it's loaded > "inside" AlicesCalendar, add the prefix "\AlicesCalendar\". All the classes > that are "inside" are completely sandboxed from the classes "outside", > without needing any interaction with a package manager. > > As far as I know, this is how existing userland solutions work, and I haven't > yet spotted a reason why it needs to be any more complex than that. > > > Regards, > Rowan Tommins > [IMSoP] >
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. So, this means we'd need a couple of different types of dependencies: 1. "direct dependencies" that work in a containerized way 2. "parent dependencies" that expect a parent to provide the dependency so it can interoperate between packages 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. That then begs the question of whether this complication is needed at all? I can understand why having a 'containerized' package system is useful (in the case of WordPress or plugins in general), but I'm wondering if it is actually needed? If we look at npm and yarn and how they handle this in the Javascript space, they basically install compatible packages when possible, and only 'contain' them when it would introduce an incompatibility. I have some ideas here, but I need some time to think on it; but I also want to point out the problem to see if anyone else has any ideas. — Rob
