On Mon, 1 Jul 2024 at 19:22, Mike Schinkel <m...@newclarity.net> wrote:
> > 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.
>
But that is why interoperability in PHP world is so high. When it was
introduced, it allowed enabling autoloading for most code bases out there
regardless of what their structure was and still is. Sure, you have to be
careful how you do it, but that is also not really a userland concern -
most of those have been implemented once and then almost never touched :)
The community has settled on a general approach since naturally and that's
how vast majority of people write their code. Buggy code is buggy code, it
really has not much to do with the autoloading and with how people write
buggy code :) You are blaming the hammer for user trying to nail the screw
into wood :)
You can already sidestep autoloader by adding a require statement to any
file and loading everything without triggering autoload. You can add your
own autoloader that has a map of high-level namespaces where you want to
load it as a package and recursively include everything that way. The tools
are there, you just need to use them. If anything, since PHP now has
attributes, you can just make yourself an attribute and handler for it and
have a `#[Package('name')]` that can find all files with that attribute and
load it all as a package.
It's far more powerful in userland because it allows people to do whatever
they want with it if they do not like the standard autoloader(s). If
anything, combined with composer folks, PHP-FIG could come up with a
community based `#[Package]` tag and make packages a thing.
>
> 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.
>
That's just how PSR-4 standard was written and works, and it's a good
default for a reason. On small projects - sure, I can see it being
overkill. But I haven't worked on a small project in a decade and I rarely
have that little code in one file that I would want to stuff all together
in one file. I do use PHPStorm, so it is very adapted to how most PHP
projects are and provides excellent navigation abilities that fit the PSR-4
and that way of structuring projects. Vast part of the community uses it.
It's a standard in a lot of companies for a reason.
>
> > 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?
>
In a positive manner - a lot of people love that they do not have to fiddle
with import statements and just can leave that part to the ecosystem and
IDE to figure out.
>
> 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.
>
See my reply to autoloading things above - you can eliminate the autoloader
triggering easily in probably 15-30 minutes flat.
>
> > 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's not that, it's literally true. PHP is one of the fastest-interpreted
languages, butting heads with nodejs only losing to it in default simple
application implementations because PHP is not event loop first (but
Franken PHP and others have a few things to say about that and then there
have been recently people playing with fibers and stuff and got performance
results that showed PHP being faster than nodejs at higher loads. Sorry I
do not have a link handly :\ )
>
> > 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
There are aspects to this that go beyond just technical aspects. Wherever
when implementing autoloading people were secret geniuses, stumbled into it
accidentally or just had practical needs themselves that they just
implemented in this way - it has been a major turning point in PHP's life
and has transformed the ecosystem into what it is today together with the
rise of the composer package manager. I have seen people talk about
visibility in namespaces, package concept and all that, but every time it
was building upon existing autoloading mechanics - some adding capabilities
to them, modifying them, having new type of autoloader. But I have never
encountered anyone in this community in 20 years i have been an active part
of it to propose a radical change like this and I'm fairly certain after
keeping up with the thread that it is almost universally not what people
want. Most people just want the toolbox be "finished" so to speak, not get
a completely new one in addition that has no compatibility with the old one.
To be frank, the PHP ecosystem just does not have the resources to eat a
change on that level and support more than one implementation. Unlike many
other languages, PHP does not really get support and investment from the
likes of google, Microsoft, meta and so on. PHP Foundation is great, but
it's not google that can singlehandedly throw 1000 devs at supporting a
language and not even really feel it.
--
Arvīds Godjuks
+371 26 851 664
arvids.godj...@gmail.com
Telegram: @psihius https://t.me/psihius
