Re: Module or Class Visibility, Season 2

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 <tendoaki@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]