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]
