Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123978
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-538-g1508afaa2-fm-20240616.001-g1508afaa
Precedence: bulk
MIME-Version: 1.0
Message-ID: <1f556e18-cefb-4a15-b96b-08118e48610c@app.fastmail.com>
In-Reply-To: 
 <CAEUnE0fGZ3jFiBG=GyvnhBzH5a0iO4=n75PM=3+6zLAMrumEvA@mail.gmail.com>
References: 
 <CAEUnE0fGZ3jFiBG=GyvnhBzH5a0iO4=n75PM=3+6zLAMrumEvA@mail.gmail.com>
Date: Thu, 27 Jun 2024 22:41:15 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from
 JavaScript
Content-Type: text/plain
From: larry@garfieldtech.com ("Larry Garfield")

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