On 14 May 2025 21:50:25 BST, Michael Morris <[email protected]> wrote:
>Container, module, block, package, plugin, domain, division, fraction,
>lump, branch, sliver, splinter, constituent or whatever the hell else you
>call it, I don't care.
I know you think I'm just being pedantic about names, but
what I was trying to get across was the distinction between different features that we could have
both of, because they're solving separate problems.
It's basically about where the dividing line is. If you want this hierarchy of dependencies:
+-- Plugin1 -- AcmeSDK v2 -- Guzzle v5
App --+
+-- Plugin2 -- AcmeSDK v1 -- Guzzle v4
The requirement is not to hide Guzzle from Plugin1 - maybe it *needs* to create an object from
Guzzle and pass it into AcmeSDK.
Instead, the requirement is for Plugin1 to hide both AcmeSDK *and* Guzzle from Plugin2. You
don't want 7 different "things" (whatever you want to call them) in that diagram, you
want 3 (App, Plugin1-and- recursive-dependencies, Plugin2-and- recursive-dependencies).
The Linux container analogy is something like this:
+-- container { WordPress -- PHP -- Apache }
Host --+
+-- container { MediaWiki -- PHP -- Apache }
The goal of containers isn't to hide WordPress from Apache or vice versa, it's to hide the
two copies of Apache and PHP from each other. There are plenty of things hidden *inside* Apache (the
equivalent of "private classes") but that's a completely separate concept.
I wasn't saying the feature had to be called "containers", just that the analogy
might be useful.
Rowan Tommins
[IMSoP]