Re: Module or Class Visibility, Season 2

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