On Thu, Jun 27, 2024, at 2:15 AM, Michael Morris wrote:
> If you got this far, thank you. This overall idea to take one of the
> better things to happen to JavaScript in the last decade and
> incorporate it into PHP has been bothering me for awhile so I figured
> I'd share. I don't know how much merit there is to this though.
There's a lot to chew on here, and some interesting ideas. However, reading through it,
there's one key question that sticks in my mind:
What problem is this trying to solve?
What problem would packages/modules/whatever be solving that isn't already adequately solved?
There seems to be a bunch of stuff kinda-sorta being addressed in this proposal, but no clear
picture of the problem being solved, and how it gets solved.
Before we get anywhere close to weeds, there's high-level questions that need to be answered.
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?
We need to know exactly what we're solving for to be able to determine if a proposal is any
good at solving it.
For me personally, 2 and 4 would be the main things to address, and if someone with more compiler
knowledge than me could do something on 5, that would be neat. 3 is, as Tim noted, a solved problem
at this point. 1 we already are working on in stages via deprecations. 6 is potentially unwise,
unless we had a good set of things that made sense to specify at a package level.
Once we know what we're trying to solve, we need to ask about constraints. The major one being
the relationship with namespaces.
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.
All the other stuff about different operators and file name extensions and stuff is completely
irrelevant until there is a solid consensus on these basic questions. For something of this scale,
to coin a phrase, "bring me problems, not solutions."
--Larry Garfield