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
