On Fri, Jun 12, 2026 at 12:54 PM Larry Garfield <[email protected]>
wrote:
> 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
Points taken. Rounding back to what I remember of last year’s conversation
with Rowain, what about containers?
Requiring a container file gets you an interface to the container living in
that file. The code execution occurs on a different thread entirely, so
calls to and from it would ideally be asynchronous.
Function or process based containers should be doable from userland
using shell_exec function (set aside a moment the security implications)
with the caveat that the whole process has to run on any call. Illustrative
of concept, but hardly production ready.
A more ideal case is for the container to return an interface that hosts
multiple methods and persists until its parent process terminates.
With some work containers might also be able to step over initialization
and config processes if a container is allowed to persist between page
requests.
Key idea here is this - put this stuff on its own process thread. That
doesn’t stop people from requiring files within the container directly.
Containerizing existing libraries involves writing the wrapper.
>
