On Sun, Jun 1, 2025, at 09:17, Rob Landers wrote:
>
>
> On Sun, Jun 1, 2025, at 07:26, Michael Morris wrote:
>> Ok, the conversation is getting sidetracked, but I think some progress is being made.
>>
>> I started this latest iteration last year with a thread about introducing something similar
>> to the ES module system of JavaScript to PHP. What attracts me to this particular model is that it
>> should already be familiar to the vast majority of PHP users. Prior to ES modules browsers had no
>> natural module import mechanic. Prior to ES modules all symbols were attached to the window. You
>> can see this if you serve open this index.html from a server (Note that opening the file locally
>> will result in the js being blocked by modern browser security. )
>>
>> ```html
>> <!DOCTYPE html>
>> <html>
>> <head>
>> <script>
>> var a = 1234
>> </script>
>> </head>
>> <body>
>> <script>
>> console.log(a)
>> console.log(window.a)
>> </script>
>> </body>
>> </html>
>> ```
>> The above spits 1234 into the console twice. Second example - let's put a module in.
>>
>> ```html
>> <!DOCTYPE html>
>> <html>
>> <head>
>> <script>
>> var a = 1234
>> </script>
>> <script type="module">
>> const a = 5678
>> var b = 9123
>> </script>
>> </head>
>> <body>
>> <script>
>> console.log(a)
>> console.log(window.a)
>> console.log(b)
>> </script>
>> </body>
>> </html>
>> ```
>> This outputs 1234 twice and an error is raised about b being undefined.
>>
>> I bring the above up to demonstrate that is the desired behavior of what I originally
>> called a PHP module and have been bullied over and taken to task about not understanding the meaning
>> of "module". Rowain seems to be more comfortable characterizing this as containers. If
>> everyone is happy with that term I really don't care - I just want a way to isolate a code
>> block so that whatever happens in there stays in there unless I explicitly export it out, and the
>> only way I see things in that scope is if I bring them in.
>>
>> The other thing that was done with ES is that the syntax for the modules was tightened.
>> JavaScripters cannot dictate what browser a user chooses, so the bad decisions of the early days of
>> JS never really went away until ES came along which enforced their strict mode by default. PHP has
>> no such strict mode - it has a strict types mode but that isn't the same thing. There are
>> multiple behaviors in PHP that can't go away because of backwards compatibility problems, and
>> one of those might indeed be how namespaces are handled. In PHP a namespace is just a compile
>> shortcut for resolving symbol names. The namespace is prefixed to the start of every symbol within
>> it. Unlike Java or C#, PHP has no concept of namespace visibility. At the end of the day it's a
>> shortcut and its implementation happens entirely at compile time.
>>
>> Previously in the discussion Alwin Garside made a long but insightful post on namespaces
>> and their workings that I've been thinking on and trying to digest for the last several days.
>> What I've arrived at is the discussions about composer and autoloaders are indeed a red herring
>> to the discussion. At the end of the day, PHP's include statements are a means to separate the
>> php process into multiple files. In his email he explored some of the rewriting that could be done,
>> and myself and Rowain have also explored this in the form of namespace pathing and aliasing.
>>
>> We've gotten away from the original focus of containing this code and how that would
>> work. So once again this moron is going to take a stab at it.
>>
>> Container modules are created with require_module('file/path'). All code that
>> executes as a result of this call is isolated to its container. That includes the results of any
>> require or include calls made by the module file itself or any file it requires.
>>
>> Since the module file is cordoned off to its own container from the rest of the application
>> whatever namespaces it uses are irrelevant to outside code. Any symbols created in the module will
>> not be established in the script that made the require_module() call. Since it is coming into being
>> with a new require mechanism it could be subjected to more efficient parsing rules if that is
>> desired, but that's a massive can of worms for later discussion. One of those will be necessary
>> - it will need to return something to the php code that called it. The simplest way to go about
>> this is to just require that it have a return. So...
>>
>> $myModule = require_module('file/path');
>>
>> or perhaps
>>
>> const myModule = require_module('file/path');
>>
>> The module probably should return a static class or class instance, but it could return a
>> closure. In JavaScript the dynamic import() statement returns a module object that is most similar
>> to PHP's static classes, with each export being a member or method of the module object.
>>
>> Circling back to a question I know will be asked - what about autoloaders? To which I
>> answer, what about them? If the module wants to use an autoloader it has to require one just as the
>> initial php file that required it had to have done at some point. The container module is for all
>> intents and purposes its own php process that returns some interface to allow it to talk to the
>> process that spawned it.
>>
>> Will this work? I think yes. Will it be efficient? Hell no. Can it be optimized somehow? I
>> don't know.
>>
>
> This could work! I have a couple of critiques, but they aren’t negative:
>
> I think I like it. It might be worth pointing out that JavaScript "hoists" the
> imports to file-level during compilation — even if you have the import statement buried deep in a
> function call. Or, at least it used to. I haven’t kept track of the language that well in the last
> 10 years, so I wouldn’t be surprised if it changed; or didn’t. I don’t think this is something
> we need to worry about too much here.
>
> It’s also worth pointing out that when PHP compiles a file, every file has either an explicit
> or implicit return. https://www.php.net/manual/en/function.include.php#:~:text=Handling%20Returns%3A,from%20included%20files.
>
> So, in other words, what is it about require_module that is different from require
> or include? Personally, I would then change PHP from "compile file" mode when
> parsing the file to "compile module" mode. From a totally naive point-of-view, this would
> cause PHP to:
> 1. if we already have a module from that file; return the module instead of compiling it
> again.
> 2. swap out symbol tables to the module’s symbol table.
> 3. start compiling the given file.
> 4. concatenate all files as included/required.
> 5. compile the resulting huge file.
> 6. switch back to the calling symbol table (which may be another module).
> 7. return the module.
> For a v1, I wouldn’t allow autoloading from inside a module — or any autoloaded code
> automatically isn’t considered to be part of the module (it would be the responsibility of the
> main program to handle autoloading). This is probably something that needs to be solved, but I think
> it would need a whole new approach to autoloading which should be out of scope for the module RFC
> (IMHO).
>
> In other words, you can simply include/require a module to load the entire module into your
> current symbol table; or use require_module to "contain" it.
>
> As for what should a module return? I like your idea of just returning an object or closure.
>
> — Rob
I just had another thought; sorry about the back-to-back emails. This wouldn’t preclude something
like composer (or something else) from being used to handle dependencies, it would just mean that
the package manager might export a "Modules" class + constants — we could also write a
composer plugin that does just this:
require_once 'vendor/autoload.php';
$module = require_module Vendor\Module::MyModule;
where Vendor\Module is a generated and autoloaded class containing consts to the path of the
exported module.
— Rob