On Sat, Jun 29, 2024 at 9:27 PM Michael Morris <tendo...@gmail.com> wrote:
> > Near universal unity?? You're forgetting Wordpress, which has massive PHP > market share (more than 50% of PHP backed websites - well more than > depending on which survey you cite) and DOES NOT USE COMPOSER. And it DOES > NOT USE PSR-4 either. > > Composer is wonderful as a userland solution to a problem the Internals > team has failed to solve, but such a critical problem as package > management being mostly solved in userland using a configuration file > (composer.json) written in another programming language entirely is frankly > an embarrassment in my opinion. > Given WP has yet to adopt Composer or PSR-4 standards, how likely do you think it is that this particular project will be quicker to adopt any, say, PHP 10 "user modules" feature along the lines of what you've proposed? > What is asking for more trouble is to stagnate, sit-on-hands, and twenty > years from now PHP will be where COBOL is today - a niche programming > language that was once widely used, but reviled, hated, and the current > generation of programmers working feverishly to remove it entirely. Not to > mention the butt of an awful lot of jokes. > Mmm, been hearing that one for the last twenty years, yet here we are. And the improvements to the language in that time have been innumerable, but each one has served as a solution to a clear problem statement. > No one is going to post to this list with a perfect plan to solve package > management in CORE. Not in userland - we've got that - in CORE. That is > a feature PHP lacks that is present in Java, NodeJS (not clientside JS, a > distinction needs to be made), C#, Python and Go (likely others, but those > are the ones I've used and whose implementations I am familiar with on at > least a cursory level.) > None of those languages have better inherent support for packages than PHP, just different ways of doing it. PHP's way is namespaces and autoloading and while there's a good case that if we were designing the language from scratch today, these might be a couple of just many things all of us might want to do differently, ultimately all these things are just variants of loading code symbols into scope. These languages all have separate tools to manage third party dependency libraries (more than one competing with each other, in some cases). Composer compares more to pip or npm or maven, not Java packages or modules in Python, JS, etc. For me, bottom line is I don't have any problem today managing or installing versioned vendor code in my projects, I don't have a problem breaking my project file structure down into clear modules and I don't have a problem referencing those modules from other modules. Nor is the way I do those things different to how any other PHP project does those things (be that via Composer, another custom autoloading function, a series of require statements, or whatever). > And I also don't appreciate the notion that any solution proposed here > should be 100% perfect and ready for implementation day one. That's never > going to happen. But I'm not willing to join several talented programmers > that have spent a month to a year getting a working implementation into > place before submitting an RFC only to have it shot down after work has > been done. Cause frankly, I think some of y'all are only here to shoot > ideas down and never come up with new ones. > What I'm saying to you is that you need something much more comprehensive, well thought out and well justified to be in a position to even have a conceptual, ready-to-consider RFC. You don't need to have a working implementation on day one but you need to be proposing something coherent and with clear benefits, which I don't think this is today.
