Re: [PRE-RFC] Runtime modules

On 28 June 2026 09:49:51 BST, Alexander Egorov <amego2006@gmail.com> wrote: >In my vision, the primary use of containers would be through supplying >proper autoloaders for them. In this case, all code inside the container >and which relies by default on autoloading (which is the majority of cases) >will load all classes in a way we expect with corresponding tags. And so we >would be able to easily match all classes. OK, then your vision is fundamentally different from mine. I don't want the container to know *anything* about how the code inside it works. Remember that autoloading is something that any library can implement its own version of. There are autoloaders which fetch from PHAR files, autoloaders which generate code on demand, and so on. Version tags break the abstraction of the container, and I don't think they solve a real problem. >Your case differs from that because, as I understand it, it loads classes >manually depending on the conditions. No, just that the container configuration doesn't know anything about "packages" or "versions". You run 'require "$someDir/vendor/autoload.php";' inside the container as normal. Or maybe you don't, and you just list a big bunch of includes for some reason. The container doesn't care. As a human author, you maybe know what versions of packages are in your container - depending how tightly you've configured them - but you have no idea what someone *else* might include in their container. If you include version 2.11 of Monolog and version 2.0 of psr/log, but some other container includes version 2.11 of Monolog and version 3.0 of psr/log, those objects aren't interchangeable. If you treat them as though they are, something is going to blow up in your face. >$client2 = $container->run(fn() => new \Google\Client); >$logger2 = $client2->getLogger(); > >match (true) { > $logger2 instanceof Logger => ...., // here I mean less formal instanceof > $logger2 instanceof LoggerV1 => ..., > $logger2 instanceof LoggerV2 => ..., >} I think you're still missing the point - if I pass around $client2, and it passes checks for "instanceof Google\Client", I can pass it to functions which have no idea it came from a different container. They will have no idea that it might return an object from getLogger() which doesn't pass a check for "instanceof Logger". >In my vision, "tag" does not really identify the container. It is whatever >we wish semantically. For example, let's say we're using Monolog\Logger 2.0 >as our "default" logger. But we also use another library which is designed >for 1.0. And for us that Logger from version 1.0 would be identified as >("1.0", Logger) according to the semantics we've chosen and which is >reflected in our autoloader. I think the only way for two containers to agree that a class is the same, is if they both start with that class name already defined, so it points to the same class entry in memory. Otherwise, containers can completely break each other by using the same tags for different definitions. >But speaking about the example you provided with google >client, it is a good example why such "polymorphic" libraries themselves >would benefit from such class-versioning and containerization and would >themselves want to switch to it to get rid of all that compatibility >shenanigans. On the contrary, the entire point of packages like psr/log is to define objects which can be passed around from one package to another. By advertising that it can be installed with multiple versions of something, a library is giving applications freedom to resolve a set of versions which works for them. That's exactly why I've been arguing for a distinction between "modules" and "containers", and saying that the vast majority of current code would not benefit from containers at all. Rowan Tommins [IMSoP]