On Sun, Jun 1, 2025, at 5:01 PM, Rowan Tommins [IMSoP] wrote: > On 01/06/2025 17:05, Larry Garfield wrote: >> I think there's a key assumption here still that is at the root of much of >> the disagreement in this thread. >> >> Given that code from multiple files is clustered together into a "thing" >> and Given we can use that "thing" to define a boundary for: >> * name resolution (what Michael is after); >> * visibility (what I am after); >> * more efficient optimizations (what Arnaud showed is possible); >> * various other things >> Then the key question is: Who defines that boundary? >> >> Is it the code*author* that defines that boundary? Or is it the >> code*consumer*? >> >> Similarly, is it the code author or consumer that has to Do Work(tm) in >> order to leverage the desired capability? Or both? > > > My take on this is that both need to exist as *separate* features. > > The author should define the boundary for things like visibility and > optimisation. It should be possible to take an existing Composer > package, add some metadata to it in some way, and have the engine make > some useful assumptions. The consumer of that package should not need to > care about the difference, except in edge cases like trying to define > additional classes with the same prefix as a third-party package. > > On the other hand, the consumer should define the boundary for isolating > name resolution. It should be possible to take any folder of PHP files, > with no metadata about package management, and load it in a context > where duplicate class names are allowed. The author of the package > shouldn't need to make any changes, except in edge cases like highly > dynamic code which needs additional hints to work correctly when sandboxed.
Were we to do that, then the consumer container-loading needs to take any potential module-definition into account. Eg, if one class from a module is pulled into a container, all of them must be. Though I'm still not clear how transitive dependencies get handled either way. Crell/Serde depends on Crell/AttributeUtils, which depends on Crell/fp. If someone wants to containerize, say, the ObjectImporter from Serde, will that necessarily mean containerizing Serde, AttributeUtils, and fp? If so, how will it know to include all of those, but not include Crell/Config (which uses Serde)? And while I know we keep trying to get away from talking about Composer and autoloading, for any of this to work, Composer would need to be modified to allow downloading multiple versions of a package at the same time and keeping them separate on disk. I do not know what that could look like. --Larry Garfield
