> On Jul 1, 2024, at 7:57 AM, Arvids Godjuks <arvids.godj...@gmail.com> wrote: > > 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.
Please note my comments that follow do not mean I am in support of this package proposal as presented. > Autoloading is one of the best killer features of PHP - love it or hate it - > it's your personal preference. Two really solid reasons to hate autoloading as implemented in PHP: 1. Autoloading runs userland code. This means it has the potential conflict between different packages with different autoloaders, it means there can be buggy autoloaders, and it means that when using XDEBUG every time a new symbol is found when the developer is single-step debugging the developer will be dropped into the autoloader and then best case they then immediately trace out. All of these aspects a major PITA and time waster and make debugging more exhausting than it needs to be. 2. Autoloading effectively necessitates that every symbol be in its own separate file. This needlessly bloats number of files and directories by more than an order of magnitude — see my numbers from recent discussion — and that also mean related code is located farther away from other related code. This can be worked around but the workarounds I've seen are all fragile and unable to be generic, and few 3rd party packages do this. > I've seen a sizeable chunk of developers that come from other languages > discover PHP's autoloading and their minds just get blown. It is unclear to me if by saying their "minds just get blown" if that means you think they see it as a positive or negative? As a developer who spent a decade in PHP and then branched out and added Go to my repertoire I can tell you one of the nicest differences I experienced was not having to deal with an autoloader during debugging, and not being so constrained was to have to create a new file for every symbol. Go projects need an order of magnitude fewer files. It is just so much easier to grok the source code of a Go project compared to a PHP because of this one simple fact. Now when I program in PHP I find myself constantly cursing the fact that I have to deal with the autoloader. BTW, I know Go is a pre-compiled language unlike PHP, but that does not necessarily preclude PHP from having a better solution for code loading and organization. > 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. This reads to me like Stockholm syndrome, e.g. "My captors still hold me captive, but they no longer beat me every day." > 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. Totally agree on that. -Mike
