> On Jul 1, 2024, at 7:57 AM, Arvids Godjuks <[email protected]> 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