Re: Two-step creation for PHP modules

On 12 June 2026 13:37:18 BST, Alex Rock <pierstoval@gmail.com> wrote: >Your "internal" system would be quite useless, because anyone would be able to do it. >It can even be done at the autoloader level if one wanted. Doesn't use Reflection or such. I honestly don't think that's a problem. If someone writes code that deliberately works around an "internal" marker, they should not be surprised when that code breaks on library updates. Right now, there is a package which dynamically removes the "final" keyword from every library installed. Does that mean "final" is useless? I don't think so. Such "escape hatches" often have legitimate uses, e.g. when writing unit tests. But see below about "sealing"... > it would kinda do the same thing as /** @internal */ today: cannot be enforced at runtime, so not safe at all. The difference is that an "@internal" marker can be *accidentally* ignored: a user can see the class mentioned, and assume they can use it anywhere in their own code. > have code that's internal on said file, with the proposed "module" system. Sure, it's only for a file, but it's better than nothing You don't need a new type of file for this, you can just add a "file-private" keyword. The only difference from adding an "export" keyword is that definitions would be public by default, in the same way methods in a class are public by default. >This way, once a define package MyPackage has been called, any >further file doing package MyPackage will throw an error Yes, this is the general idea behind my remark about "sealing" a namespace: some way to say "all symbols in this namespace are loaded, do not allow more to be added". As well as stronger enforcement of boundaries, that would allow OpCache to do "link-time" optimisations and multifile caching. It doesn't solve the "containerisation" problem (running multiple copies of the same library in different contexts), but I think that needs to be at a wider scale still: if you run two versions of Guzzle, you need to two versions of PSR interfaces to go with them, and so on. I think it needs some way for the *consumer* of the code (e.g. a WordPress plugin) to define what's "inside" and "outside" the container. I don't think it's actually necessary (or useful) for a "container" system to depend on a "package" system at all - the ideal is to say "all files included in this directory are inside the container", without any cooperation from the author of those files. So I think both "packages" (a way for the author of Guzzle to define a visibility and optimisation boundary) and "containers" (a way for a WordPress plugin to load a whole vendor directory without causing name conflicts) are useful ideas to discuss, but trying to talk about both at once leads to a lot of muddle. Rowan Tommins [IMSoP]