Howdy people,
> On Jul 1, 2024, at 11:07 AM, Dusk <[email protected]> wrote:
>
> On Jul 1, 2024, at 09:22, Mike Schinkel <[email protected]> wrote:
>> 2. Autoloading effectively necessitates that every symbol be in its own separate file.
>
> How so? While Composer "recommends" PSR4 autoloading with one class per file, other
> configurations are entirely possible, either with Composer's autoload.classmap (which uses a
> precomputed class -> filename table), or with a custom autoloader.
If I'm understanding the main issue, we need package-level scope.
Rather than build a whole new thing, what if we solve this problem?
Thought:
What if php implicitly prepended namespaces with the composer package version?
If two incompatible versions are required, the composer downloads both. Enabled/Disabled with flag?
Maybe: org/package/version/
This implicit version would show in debug backtraces. So importing Example\Example; might look like
this in the trace:
1.0.8\Example\Example
Packages imports by namespace could automatically resolve to the version defined in that file's
local package JSON.
Reflection to know where the code is running is easy enough, but this would require
interpreter-level changes.
It’s a little late, but off the top of my head, it seems fairly backward-compatible.
However, if someone relies on parsing a stack trace… hmmm (trace flag too?)
Contextual sidenote:
Mac doesn’t ship with brew. Windows doesn’t ship with Chocloaty.
Python ships with pip, and Node ships with npm.
Python didn’t start shipping with pip until version >= 3.4.
I would be happy to see PHP shipping with the composer as a default-enabled flag.
Best,
Richard Miles