On Fri, Jun 12, 2026, at 7:37 AM, Alex Rock wrote:
> What if we have this:
>
> <?php
>
> // vendor/my-library/src/MyClass.php
>
> namespace MyNamespace;
>
> internal class MyClass {};
>
> Fine code would look like this:
>
> <?php
>
> // index.php
>
> function main() {
> $o = new \MyNamespace\MyClass(); // Fatal Error: cannot create
> instance of internal class MyNamespace\MyClass
> outside of the MyNamespace namespace
> }
>
> And "not fine code" would look like this:
>
> <?php
>
> // index.php
>
> namespace MyNamespace {
> function createObject() {
> return new \MyNamespace\MyClass();
> }
> }
>
> namespace {
> function main() {
> $o = \MyNamespace\MyHack::createObject(); // Works.
> }
> }
>
> 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.
But it would allow a workaround to access a private class for testing. (And
no, "it's private so you can't test it" is not the answer. Classes may be
black boxes, but for testing purposes, modules are not and should not be. And
in PHP, tests cannot be in the same file as the thing being tested.)
> Then, it leads to your first question:
>
>> On 11 June 2026 09:12:52 BST, Alex Rock <[email protected]> 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?
> Well, to solve the previously shown issue.
>
> The "internal class" previously set (or moved to "internal namespace":
> same issue) is useless, and it would kinda do the same thing as /**
> @internal */ today: cannot be enforced at runtime, so not safe at all.
>
> There's no need to add "internal class" if this system doesn't
> internalize anything and is easily "hackable" from outside.
>
>
>
> If you want to have *actual* internal code, there are only two ways to
> achieve this:
The biggest problem with discussions about modules in PHP is that there is no
consensus on what problem we're even trying to solve. Visibility?
Double-loading? Non-PSR-4 file organization? Performance? Enforcing PSR-1
"just declare symbols" rules?
Ask 10 people on this list and you'll get 12 different combinations of desired
features. Trying to solve the How before we agree on the What is why we keep
going in circles every year or so.
(This would be an excellent use case for a chartered Working Group, as Ben has
proposed.)
> - 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
> - have a "package" system so that a package has an entrypoint that
> defines private and public files, and said files expose which "package"
I would strongly urge everyone to keep to the terminology proposed here:
https://github.com/Crell/php-rfcs/blob/master/modules/spec-brainstorm.md
"Package" already means "thing you download via composer." It's a unit of
distribution. Trying to redefine it to mean "a unit of scope" is just going to
create confusion.
>> I'll say it one more time, then stop: any solution needs to start with what
>> we have, and what we have is namespaces.
> In that case, let's move directly to "packages" without talking about
> "modules" at all, and make namespaces package-aware somehow. Or the
> contrary: make a package implicitly create "protected" namespaces.
Please see the link above, in detail. Arnaud and I went very far down this
rabbit hole. Make sure you've seen the prior art before you try to go down it
again.
One other thing I'll note: In today's autoload-based PHP, *you do not know the
path to a given class*. That is by design. There is no rule that composer
won't reorganize the contents of vendor at some point. Hard coding a path into
a file to get from that file to some other file in the file tree is a PHP4-ism
we should leave to that era. So module inclusion statements that require
knowing the path from one file to another is an immediate dead end.
--Larry Garfield
