On Thu, Jun 27, 2024 at 1:02 PM MKS Archive <mikeschin...@gmail.com> wrote:
> > Interesting to see this. Serendipitous given the email I sent on the list > in reply to Larry. > > My initial thoughts: > > 1. I really like the concept of cleaning up issues that BC make impossible > to fix by introducing modules. > Thanks. The sticking point is what degree of change should be occurring. PHP isn't as behind an 8-ball as JavaScript is since the dev can choose their PHP version and hence deprecation works most of the time for getting rid of old stuff. But not always. Changes that are incompatible with what came before need a way to do things the old way during transition. Again, see PHP 6 and unicode, which snowballed until it was clear that even if PHP 6 had been completed it wouldn't be able to run most PHP 5 code. > 2. No need for autoloaders with modules; I assume this would be obvious, > right? > > Depends largely on whether modules can include and require to get access to old code. I also didn't discuss how they behave - do they share their variables with includes and requires? > 3. Not a good idea to use an ini setting; most view them to be problematic. > 4. .htaccess îs Apache-only, so a non-starter anyway. > 5. The first script should not be a module. If you want that, have a 1 > line index.php file do an import. > I love this idea. > 6. Modules should be directories, not .php files. Having each file be a > module makes code org really hard. > Yes, but that is how JavaScript currently handles things. It is currently necessary when making large packages to have an index.js that exports out the public members of the module. This entry point is configurable through the package.json of the module. > 7. Modules would have a symbol table metadata file generated by IDEs and > during deployment. > Node.js uses package.json and the attendant npm to do this sort of prep work. And it's a critical part of this since modules can be versioned, and different modules may need to run different specific versions of other modules. > 8. If no metadata file in directory PHP can generate one in memory during > first directory access. > 9. .php files in modules as identified by metadata file should not be > loadable via HTTP(S). > Those are implementation details a little further down the road than we're ready for, I think. > 10. Having exports separate from functions and classes seems like it would > be problematic. > Again, this is how they work in JavaScript. Not saying that's the best approach, but even if problematic it's a solved problem. > 11. Exports could be implemented as attributes, which could be really > elegant. > 12. Exports as attributes pairs with the symbol on the line above, and > would enable easy aliasing. > Ultimately everything in JavaScript is an object. JavaScript provides a mechanism for handling a module file with a single default export, but it supports multiple exports from the same file which arrive as an object best approximated in PHP as a static class. I could hash out further, but again, I'd like to gauge some interest and very high level feedback. I'm also interested in learning on how other module systems out there do work. I'm picking of JavaScript because most of the PHP community has to use it as well for client side scripting and so most of us should have at least passing familiarity with it. > 13. And finally, when are you starting the RFC? :-) > It's too early for anyone to start at this moment - and while I certainly am willing to help I'm not qualified to take the lead on this. If adopted, this is a massive change, and the results of this conversation won't hit for years. Let's take our time. For one, this overarching project will need multiple coordinated RFC's, as well as figuring out what to do and also in what order.
