Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124156
Content-Type: text/plain;
	charset=us-ascii
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: <4D45294E-78BA-466A-B2B4-F17BA4E1ED73@woofle.net>
Date: Mon, 1 Jul 2024 14:07:34 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <7593EA45-DF41-43DE-9EAD-F3CCFC8A7D47@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>
 <09559430-4477-4516-8D78-6F4071E1AA6C@newclarity.net>
 <4D45294E-78BA-466A-B2B4-F17BA4E1ED73@woofle.net>
To: Dusk <dusk@woofle.net>,
 Arvids Godjuks <arvids.godjuks@gmail.com>
From: mike@newclarity.net (Mike Schinkel)

> On Jul 1, 2024, at 1:07 PM, Dusk <dusk@woofle.net> wrote:
>=20
> On Jul 1, 2024, at 09:22, Mike Schinkel <mike@newclarity.net> wrote:
>> 2. Autoloading effectively necessitates that every symbol be in its =
own separate file.
>=20
> How so? While Composer "recommends" PSR4 autoloading with one class =
per file, other configurations are entirely possible,

I spoke inartfully, sorry.=20

The culture of projects throughout the PHP ecosystem has resulted in =
most projects being one class per file, and there have not evolved any =
defecto-standard tools for creating those classmaps further ensuring =
PSR4 ubiquity.

> either with Composer's autoload.classmap (which uses a precomputed =
class -> filename table), or with a custom autoloader.

And, refer back to reason  #1 to hate autoloading in PHP.

> On Jul 1, 2024, at 1:28 PM, Arvids Godjuks <arvids.godjuks@gmail.com> =
wrote:
>=20
> 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 :)=20

Two things can be true at the same time.  Something can have a =
historical benefit but not be ideal moving forward when compared to =
potential future alternatives.

The major benefit that autoloading has today is inertia. Yes, that's a =
huge benefit. But that does not make autoloading beneficial.

> You can already sidestep autoloader by adding a require statement to =
any file and loading everything without triggering autoload.=20

There is not a standard way to sidestep the autoloader that has majority =
support in 3rd party packages. It's a roll-your-own thing.

> 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).=20

The only reason people think about how they want autoloading to work is =
because they have to. Technology is supposed to evolve to eliminate rote =
and low-value add tasks.

By the same token I could say we should introduce the ability in =
userland for people to modify the implementations of standard library =
functions so people could do whatever they want with it if they do not =
like the standard implementations.=20

But clearly that latter would be crazy talk.

> 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.

Again, I will say this is Stockholm syndrome.

> See my reply to autoloading things above - you can eliminate the =
autoloader triggering easily in probably 15-30 minutes flat.=20

But to do so there is not one single way that is reality standard. So I =
have to own maintenance of that low-value code.

> 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=20

That is probably because you all have been working mostly in PHP and not =
experiencing better alternatives. BTW, NodeJS/Javascript is NOT a better =
alternative, IMO.

Besides, what I proposed earlier was not a "radical change." =
Characterizing something as "radical" is just a rhetorical tactic used =
to discredit said thing. What I proposed was very incremental and would =
allow all existing code including autoloaders to co-exist with a =
module/package concept. Not radical.

> 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.

I get it. I am no longer proposing an alternative to the autoloader. PHP =
developers are comfortable with autoloading and that is that.

But that does not mean that I cannot tell you and others the emperor has =
no clothes in hopes that people eventually see that there can be better =
alternatives.

-Mike=