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 <[email protected]> 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]