Re: [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

From: Date: Fri, 28 Jun 2024 14:05:25 +0000
Subject: Re: [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript
References: 1 2  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
First of all a quick note for the OP: I am all for it in general, but I don't think copying the entire JS module system one to one makes sense. It contains a lot of compromises and mistakes that we should absolutely learn from as well as the good things they did.

On 2024-06-28 00:41, Larry Garfield wrote:

Which of these are we trying to solve? (Solving all of them at once is unlikely, and some are mutually-incompatible.) 1. Adding a "strict pedantic mode" without messing with existing code? 2. Package-level visibility (public, package, protected, private)? 3. Avoid name clashes? 4. Improved information for autoloaders and preloading, possibly making class-per-file unnecessary in many cases? 5. A larger scope for the compiler to analyze in order to make optimizations? 6. Package-level declares, inherited by all files in the package? 7. Something else?
I agree with most of your analysis, and IMO Package-level visibility is the main direct win, with a larger scope for JIT optimization coming later. It would however be very tempting to bake in 1, and remove a bunch of things which are not removable from the language at large due to BC, as that might be a once in a lifetime opportunity. Some features make JIT optimizations nearly impossible (Nikita had a list somewhere.. but the main one if probably killing references). The autoloader information to be honest I am not sure how important this is. For everyone not wanting to do class-per-file, note that you can just use "classmap" autoloading in Composer. It is anyway the most performant option at runtime [1]. The only catch is you have to re-dump the autoloader when adding new classes/files to make them discoverable. But I think everyone's kinda too stuck on PSR-4 because it is a standard.
Do we want: 1. Packages and namespaces are synonymous? (This is roughly how JVM languages work, I believe.) 2. Packages and files are synonymous? (This is how Python and Javascript work.) 3. All packages correspond to a namespace, but not all namespaces are a package? And given the near-universality of PSR-4 file structure, what impact would each of those have in practice? (Even if packages open up some new autoloading options and FIG publishes a new PSR for how to use them, there's only a billion or so PSR-4 class files in the wild that aren't going away any time soon.) My gut feeling is we want 3, but I'm sure there's a debate to be had there.
I'd go for 3 as well. Every package having a single root namespace is probably true of 99% of packages due to the PSR-4 autoload root. Sub-namespaces are discretionary. [1] https://getcomposer.org/doc/articles/autoloader-optimization.md -- Jordi Boggiano @seldaek -https://seld.be

Thread (128 messages)

« previous php.internals (#123988) next »