On Sun, Jun 30, 2024, at 8:28 PM, Michael Morris wrote: > So let's take another crack at this based on all the points raised in > the thread. This should also underline why I don't consider this an RFC > - I am iterating until we arrive at something that may be refinable > into an RFC. And I say we because without the aid of those in this > conversation I would not have arrived at what will follow. > > Before I continue I would like to apologize for being somewhat > irritable. We're all here because we enjoy using this language and want > to see it improved and prevent bad changes. Opinions will differ on > this and in the heat of the moment of arguing a point things can get > borderline. > > > Returning to a point I made earlier, Composer isn't used on Wordpress. > I went over to the Wordpress discussion list and read over why, because > that discussion provides clues to what kind of package management may > be adoptable. I think the largest point is that Wordpress should be > usable without ever resorting to using the command line. Yes, it does > have a command line tool - wp-cli - and it is powerful, but using it as > an administrator of a Wordpress site is not required. > > The largest block to composer's inclusion in Wordpress is the inability > to run multiple versions of a module. Yes, it's a mess when this > happens, but if you're an end user, you just want your plugins to work. > If one plugin that no one has updated in a year that you're using is > consuming version 2 of a package, you're gonna be annoyed at best if > the module stops working when you install a new plugin that is using > version 3 of the same package and has a BC break in it. Composer can't > resolve this easily.
There's still a few key, fatal issues in this version of the proposal. 1. It appears like it expects PHP to be able to write to disk itself as part of normal operation. This is an immediate fatal flaw. Most security best practices these days recommend that the disk where code is be read-only. Some hosting companies mandate it. Any language feature that precludes that is dead in the water. 2. Supporting multiple versions of the same class is *waaaay* out of scope. You seem to imply Composer is the reason we cannot do that. That's incorrect. PHP has a single global symbol table for classes. (And a separate one for functions for not-great historical reasons.) Trying to define the same class twice will fatal the engine. While there are some screwy conditional-include games you can play, they're fragile and still would not allow WP Plugin A to use v1 of a library and WP Plugin B to use v2 of a library. I am not versed in that part of the engine, but I would be shocked if splitting up the global symbol table was possible, let alone feasible. 3. Using URLs as the package naming system is the dumbest thing Go ever did. Let's not replicate that. :-) I think the core problem here is that this thread keeps trying to graft Python/Go/JS/Rust style packages onto PHP. PHP, however, is structurally closer to Java/C#, so following that package logic (which is built off of namespaces) would be far more natural, and thus far easier to migrate to. Really, the only targets we should be looking at, IMO, are: 1. Package-level visibility. 2. Giving the compiler/optimizer/JIT a larger "scope" of code to compile/optimize at once, so it can do smarter things. I think everything else is a distraction. I have some thoughts on how we can far more easily accomplish 1, and maybe 2, but I will probably hold off on that for now as it would just get lost in the noise of this thread, plus the list is too busy as is these days with everyone trying to get their in-flight RFCs finalized before the feature freeze deadline. :-) (Really, this is a poor time to be having this kind of discussion. Fall is generally the better time, just logistically.) --Larry Garfield
