On Thu, Jun 27, 2024, at 21:23, Michael Morris wrote: > > 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.
It’s not just up to the dev, but the libraries we use and whether or not we can easily upgrade (or remove) them to upgrade the php version. > >> 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? I think it would be a mistake to exclude old code and/or prevent templating. Not only are there now decades old code in some orgs, but how would you write an email sender that sent templated emails, provide html, generate code, etc? There has to be an output from the code to be useful. > >> >> 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. I think it’s fine to use js as an inspiration, but it isn’t the only one out there. There is some precedent to consider directories as modules (go calls them “packages”) and especially in PHP where namespaces (due to PSR-4 autoloading) typically match directory structures. For example, I’m still going to go forward with my #[Internal] attribute RFC some time in the next month or so, which will be namespace based. I have no idea if it will pass, (some people are worried about it clashing with an RFC like this one) but I think we’d have value in it for years to come until something like this gets fleshed out. We will see… > >> 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. Please, please, please do not make a json file a configuration language. You can’t comment in them, you can’t handle “if php version <9, load this, or if this extension is installed, use this.” Maybe that is desirable, but doing things slightly different based on extensions loaded is def a thing. > >> 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. Personally, if these are going to have any special syntax, we probably shouldn’t call them .php files. Maybe .phm? > >> >> 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. the only thing I don’t like about this import/export thing is that it reminds me of the days when we had to carefully order our require_once directives to make sure files were loaded before they were used. So, I think it is worth thinking about how loading will work and whether loading can be dynamic, hoisted out of function calls (like js), how order matters, whether packages can enrich other packages (like doctrine packages) and if so, how much they can gain access to internal state, etc. This is very much not “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. In JavaScript, arrays are instances, in php, they are values. This is something to consider if a module exports an array of exports. > >> >> 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. — Rob
