Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128086
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 16 Jul 2025 10:57:04 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <1ecc1fd2-3837-4409-98c8-543b26de4955@app.fastmail.com>
In-Reply-To: 
 <CADK1yXKG9px-FdDf=57uBOKiXfdMDFd5o6RXcPPhy1XAiRWKig@mail.gmail.com>
References: 
 <CANTuiHtqmkZNRqfiuB107a+7GMcL88R9S-Q7+rOafKhZtZtFxg@mail.gmail.com>
 <ea012907-5961-4b02-93e3-836ef69f88fb@app.fastmail.com>
 <CADK1yXKG9px-FdDf=57uBOKiXfdMDFd5o6RXcPPhy1XAiRWKig@mail.gmail.com>
Subject: Re: [PHP-DEV] Discussion Short Constructor
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Jul 16, 2025, at 10:44 AM, Deleu wrote:
> On Wed, Jul 16, 2025 at 3:49=E2=80=AFAM Rob Landers <rob@bottled.codes=
> wrote:
>> __
>>=20
>> Why I haven't proposed it as a separate RFC: with PSR-4 being so popu=
lar, nobody is going to write one-line files to take advantage of this. =
Thus, when I was going to revisit nested classes later this year (after =
all the release shenanigans and some personal issues), I was planning to=
 add this feature to the nested class v2 RFC (again). A lot of feedback =
I got on nested classes was "when would I use this?" -- and I suspect th=
at would be a lot of the feedback you'd get here (see: PSR-4). I'm more =
convinced than ever that short constructors and nested classes create a =
chicken-and-egg problem. They only really make sense together; at least =
with our current coding conventions and standards. It will create a long=
er discussion period, but that's fine, IMHO.
>>=20
>> If you'd like to continue with this RFC, I'd love to discuss it furth=
er with you and help you out. I believe it is a bit more than "just" syn=
tax sugar, but I'd have to dig out my records implementation.
>>=20
>> =E2=80=94 Rob
>
> I remember PHP from ~2000's and PSR-4 and Composer were probably one o=
f=20
> the biggest improvements to the ecosystem. However, I feel like a "2.0=
"=20
> version is long overdue. I have participated in some internals=20
> discussions that point out a fact from the other direction: PHP makes=20
> no imposition about file structure. 1-class-per-file is strictly a=20
> PSR-4 implementation of a custom autoloader which we have gotten used=20
> to for so long. I would really love to be able to declare small relate=
d=20
> classes/interfaces in a single file much like we can do with=20
> Typescript, but the current state of PHP "register your autoloader=20
> however you would like it" vs the current state of the community "PSR-=
4=20
> is THE standard", we end up between a rock and a hard place. I don't=20
> particularly enjoy nested classes and how the syntax and its contexts=20
> get involved. Sure it would be nice to have private classes, but it=20
> gets quite cumbersome to have to do it while nesting classes within=20
> classes.

I will reiterate what I have said many times in the context of function =
autoloading:

The only autoloader that really matters in practice is Composer.

Composer supports "front-load this list of files".  You can put whatever=
 you want in there.

We have an opcache.  I am really not concerned about the cost of front-l=
oading a bunch of small functions or classes. =20

If you're using React, FrankenPHP, or many of the other new-wave run mod=
els, you have a persistent process anyway so just expect everything to g=
et loaded.

So having a "dto.php" or "classes.php" file that Composer just front-loa=
ds on every request that contains a bunch of one-liner class definitions=
 (or functions, or whatever) is perfectly fine, and works today.

The only thing that would need to change is for SA tools (mostly PHPStor=
m) to be less whiny if they see a class that doesn't match its file name=
.  But I am quite confident JetBrains can figure out how to do that.

In short: This is not a real problem.  There's no need for us to make it=
 one.

--Larry Garfield