Re: Two-step creation for PHP modules

On 11 June 2026 09:12:52 BST, Alex Rock <pierstoval@gmail.com> wrote: > >Namespace visibility could be implemented, but if you want to have some public code that uses >"include" to get access to some other private code in the same namespace, or >sub-namespace, then you would somehow hav to specify to whom this namespace becomes visible. Why would you need that? > namespace visibility would still be easily "hackable" without having to touch > PHP's internals (like from using Reflection). Visibility isn't a security tool, it's a helper to stop people making mistakes. > That's why some CS fixers enforce adding "use function" or add the "\" > root namespace to function calls, to prevent from overriding native functions. I believe that's actually about performance: if you don't specify, the engine has to try the lookup on every call, in case a namespaced function was registered. > So far, I don't see how namespace/file visibility would help if you don't have a > bi-directional definition system. It's really, really simple: you mark the internal parts "internal". Then you use them from all the same places they're intended, inside the package's namespace; and people using them outside those intended places get a helpful error message that they're using the library wrong. It's possible we also want to add a way to "seal" the namespace against new definitions anyway, to help with optimisation. Namespaces, not files, would still be the right starting point for that. >- It still allows creating a namespace from anywhere else in order to "hack" into it >and publicly expose an API that wasn't supposed to be exposed at all. Non-issue: as above, visibility is not a security tool. >- It doesn't solve the issue of having the same package in different versions, since >namespaces will be the same A solution to that which requires hundreds of thousands of libraries to rewrite all their code to use relative references rather than namespaced global names isn't going to get very far. I'll say it one more time, then stop: any solution needs to start with what we have, and what we have is namespaces. Rowan Tommins [IMSoP]