On Sun, 30 Jun 2024 at 23:30, Michael Morris <tendo...@gmail.com> 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. > > *snip* > > TL;DR: As a userland developer, in my opinion, this is just a downgrade from what we have now. Enhance namespaces to have the ability to have internal/private classes, interfaces, enums and constants. That's about it. Autoloading is one of the best killer features of PHP - love it or hate it - it's your personal preference. I've seen a sizeable chunk of developers that come from other languages discover PHP's autoloading and their minds just get blown. Performance has not been an issue for a long time due to opcache and all the optimizations that have been done to it and ability to preload bytecode. Then there are things like FrankenPHP, Swoole, ReactPHP and others that entirely sidestep that issue. And then there's the active development of JIT engine - just let the people working on the implementation time to cook. It works, worked for a long time and there are not so many things wrong with it to entirely upend the whole ecosystem and split the language. Here's your HARD REMINDER about Python 2 => Python 3 and how that went and is still somewhat ongoing. Sometimes copying things from other places is just wrong and does not fit the ethos of the language you want to change. PHP always was and still is "doing it's thing". Practicality is on the high list of priorities here and that is why many of us have chosen the language and stuck with it 2 decades in. The only thing I want to be added to namespaces is the ability to define internal classes, interfaces, enums and constants so that when you write application code, the internals of packages and your own code's "private" details do not leak to the business level layer via autocomplete suggestions and in general reducing the cognitive load of that aspect. And there are obvious advantages of locking down the internals of a library so people do not abuse it and then complain when things get broken. And i don't even want to comment how you want to bring composer functionality into PHP code and make it a weird combo of PHP, composer, docker-compose.yml - insert the "WHY?!" meme here. What I love about PHP ecosystem is for the most part, every tool has its main job and it does that job exceedingly well. PHP core is developing the engine and doing a great job. Composer is doing its job and it is the best package management tool out there. And so on - we have one of the best quality ecosystems around because things are not jammed into each other and trying to create a "supertool". There is something to be said about Internals refusing to if not endorse, at least acknowledge the popular tooling and lean on it more (like rector for upgrades and so on), but that is a completely different discussion. The PECL is being worked on to be replaced, so we can't even raise that point any more - PHP Foundation is taking care of it. --- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Telegram: @psihius https://t.me/psihius
