On Mon, Jun 2, 2025 at 10:40 PM Larry Garfield <la...@garfieldtech.com>
wrote:
> On Mon, Jun 2, 2025, at 3:28 PM, Rowan Tommins [IMSoP] wrote:
> > On 02/06/2025 17:57, Larry Garfield wrote:
> >> Well, now you're talking about something with a totally separate
> compile step, which is not what Michael seemed to be describing at all.
> But it seems like that would be necessary.
> >
> >
> > There's definitely some crossed wires somewhere. I deliberately left
> > the mechanics vague in that last message, and certainly didn't mention
> > any specific compiler steps. I'm a bit lost which part you think is
> > "not what Michael seemed to be describing".
> >
> >
> >
> > Picking completely at random, a file in Monolog has these lines in:
> >
> > namespace Monolog\Handler;
> > ...
> > use Monolog\Utils;
> > ...
> > class StreamHandler extends AbstractProcessingHandler {
> > ...
> > $this->url = Utils::canonicalizePath($stream);
> >
> >
> >
> > My understanding is that our goal is to allow two slightly different
> > copies of that file to be included at the same time. As far as I know,
> > there have been two descriptions of how that would work:
>
> This is what I was getting at. As I understand what Michael's examples
> have described, it allows pulling a different version of one or more files
> into some kind of container/special namespace/thingiewhatsit, at runtime.
>
At some point that could be a fair assessment of what I was saying. I'm
coming around to Rowain's container view though, enough to start thinking
of this as container modules. I don't want to get in the weeds of how the
files for a container module get set up by whatever package manager is
chosen as that's a massive problem to solve in its own right. For now I
would like to focus on this idea of having a container that can do whatever
it needs to do without affecting the code that started it in any way.
Avoiding the enormous code/file duplication that will result from this is a
separate, later problem and admittedly might not be solvable. But having a
container mechanism, even if it isn't optimized, would be healthier than
having plugins that carry their own Stauss monkey-typed copies of the
libraries they need even if those are several minor versions behind (which
should be compatible if the author obeys semantic versioning).
