Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124146
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial
 Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)
In-Reply-To: <CAL0xaBFWUkeMk=ofOF4q+keVN6X3nx67NjZ1-2zWfgGez1oy4Q@mail.gmail.com>
Date: Mon, 1 Jul 2024 12:22:24 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <09559430-4477-4516-8D78-6F4071E1AA6C@newclarity.net>
References: <CAEUnE0fGZ3jFiBG=GyvnhBzH5a0iO4=n75PM=3+6zLAMrumEvA@mail.gmail.com>
 <CADK1yX+E9mvaM_CHJ8tmEx=O70hf8xasbvngh4wvNM8ce8KKGQ@mail.gmail.com>
 <B5DC69B8-E044-47FB-B81C-307E2C19CB66@newclarity.net>
 <1917CF7C-26D8-4DBE-B05C-5AA650AC6C9F@rwec.co.uk>
 <551cd5b0-1c00-4818-a9ca-97f6b7e8c3dc@app.fastmail.com>
 <CAEUnE0fNxSHN4QGfm6ETMVdE5Mcm1AEebmWs7i9xDNgcWnvQvw@mail.gmail.com>
 <39B496F8-062E-4848-9B3B-529BE8D3415A@newclarity.net>
 <CAEUnE0fOfU1tJNKXuBqbSm8jsp7gqe_JY-SiipdUKNztcx0Rog@mail.gmail.com>
 <856F4F70-DC81-4098-82DD-5F6D47CDF3F0@newclarity.net>
 <CAEUnE0c0fW9xnQOtLgj1zTpvdfixSHuLeLA7HOqDTkpr4hJ84g@mail.gmail.com>
 <CAEUnE0dSUY2VKji_o-AgQ-YZMf7viwCZh1sa8ScHdS7ihUgfUQ@mail.gmail.com>
 <CAL0xaBFWUkeMk=ofOF4q+keVN6X3nx67NjZ1-2zWfgGez1oy4Q@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>
From: mike@newclarity.net (Mike Schinkel)

> On Jul 1, 2024, at 7:57 AM, Arvids Godjuks <arvids.godjuks@gmail.com> =
wrote:
>=20
> 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.=20

> 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 =E2=80=94 see my numbers from recent =
discussion =E2=80=94 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 =3D> Python 3 and how =
that went and is still somewhat ongoing.

Totally agree on that.

-Mike=