Re: [PRE-RFC] Runtime modules

On 27/06/2026 17:45, Alexander Egorov wrote:

As for passing objects between containers, it does not seem like an unsolvable problem. Even though our thoughts are very abstract for now, generally speaking there could be some matching of objects in inter-container usage. Like, if "my" container is now using \My\Namespace\SomeObject from my dependencies (let it be, say, myvendor/mylib: 1.0), when receiving such an object from another container, it could be known what exact dependency it is from. And if it is also myvendor/mylib: 1.0 - there should be no problems. If versions don't match, there could be some explicit inter-dependency mapping defined by the user, or an explicit runtime error if no mapping was provided.

Just knowing the version / source of an individual class is not enough. At the very least, you need a fingerprint that also includes the versions of the classes it inherits from, the interfaces it implements, and the traits it uses. And then what about other relationships, like the classes they create and return? For example: class WidgetFactory {    public function makeWidget(): Widget { ... } } $factoryA = new WidgetFactory(); $factoryB = $someContainer->run(fn() => new WidgetFactory); $widgetA = $factoryA->makeWidget(); $widgetB = $factoryB->makeWidget(); If the container contains the same version of WidgetFactory, but a different version of Widget, what objects do I end up with?

Like, when "starting" a new container, the only thing we need to provide is a class-loader, which would presumably "tag" the loaded classes in a known manner. In the case of composer, it could tag them by version. In our code, we could import all needed classes with some advanced syntax with specifying the "tag". As an example from the top of my head: use \My\Namespace\SomeObject tagged "..." [as SomeObjectV1], explicitly telling which version we need. And we could have both versions imported this way (and map one to another, accordingly).

This feels like it's moving much more back to the "module" idea - changes which have to propagate deep into existing code before you can use them. To me, the guiding principle of containers needs to be that the configuration all exists *at the boundary of the container*. I'm thinking of the EXPOSE and VOLUME keywords in a Dockerfile, for example. -- Rowan Tommins [IMSoP]