On Fri, Jun 12, 2026 at 12:54 PM Larry Garfield <[email protected]>
wrote:
> I would strongly urge everyone to keep to the terminology proposed here:
>
> https://github.com/Crell/php-rfcs/blob/master/modules/spec-brainstorm.md
Done, that's a VERY interesting resource, thanks! I see that some of my
ideas are close to what you brainstormed, and I have another point of
view of how it can be implemented :)
Using an INI file definitely makes sense if it needs these three keys to
be defined somehow.
I'll try to reuse your wording for clarity and consistency :)
Le 12/06/2026 à 19:25, Michael Morris a écrit :
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:
> 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.)
One of the goals of modules is to encapsulate more elements of a module
or package than just class methods, therefore private/internal elements
of a module should not be accessible from outside, that's exactly the
point of it. So yeah, "it's private so you can't test it" still has to
apply, as said, just like you shouldn't test your private class methods
(even though PHP allows it with hacks).
> 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?
On my side:
1. Allowing internal code units, not exposed to the outside of a package
or module, but accessible from within it.
This is for maintainers to have a much easier way to define
non-BC-covered code.
2. PSR-1 "just declare symbols" is, indeed, something I personally would
like to happen. But technically, this is the "first step" of my initial
thread, the one with "definition files", and it's really easy to do (I
have a branch on php-src for that). This is to ensure loading a PHP file
has zero side-effect after being compiled.
3. Allowing multiple modules with same names to be loaded at the same
time, as long as they are different files.
If these are problems that a sufficiently enough portion of the
community would like to solve, then I think we should go for it somehow :)
Your implementation proposal makes everything internal by default, AND
allows using a specific keyword to expose parts of a structure, or the
whole structure, to the outside world. This is partly similar to what I
already have in mind for what I called "packages", because I pictured
"module" as being a single file and its module-inclusion tree (similar
to Rust crates, and Node.js local-file-imported modules)
What's missing, for now, is a method to allow two modules of same names
to coexist.
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.
Seems like a dead-end based on all counter-arguments I've been having
since I started the discussion, so I'll have to follow this movement I
guess :D
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.
Containers as "code block that's executed in another thread" seems like
something completely different than implementing modules, or am I
missing something?
