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
