On 14 May 2025 21:50:25 BST, Michael Morris <tendo...@gmail.com> 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]
