Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128088
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 16 Jul 2025 19:29:36 +0200
To: =?UTF-8?Q?Marco_Aur=C3=A9lio_Deleu?= <deleugyn@gmail.com>
Cc: internals@lists.php.net
Message-ID: <ba2d0f70-f9c9-4625-9f20-89bc480677e1@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: multipart/alternative;
 boundary=a3226ad1db4342909824fb3cc03cb119
From: rob@bottled.codes ("Rob Landers")

--a3226ad1db4342909824fb3cc03cb119
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 16, 2025, at 17:44, Deleu wrote:
>=20
>=20
> 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
>=20
> I remember PHP from ~2000's and PSR-4 and Composer were probably one o=
f the biggest improvements to the ecosystem. However, I feel like a "2.0=
" version is long overdue. I have participated in some internals discuss=
ions that point out a fact from the other direction: PHP makes no imposi=
tion about file structure. 1-class-per-file is strictly a PSR-4 implemen=
tation of a custom autoloader which we have gotten used to for so long. =
I would really love to be able to declare small related classes/interfac=
es in a single file much like we can do with Typescript, but the current=
 state of PHP "register your autoloader however you would like it" vs th=
e current state of the community "PSR-4 is THE standard", we end up betw=
een a rock and a hard place. I don't particularly enjoy nested classes a=
nd how the syntax and its contexts get involved. Sure it would be nice t=
o have private classes, but it gets quite cumbersome to have to do it wh=
ile nesting classes within classes.

I won't comment on the composer stuff or autoloading for that matter. Bu=
t to your point about nested classes -- well, the entire point of nested=
 classes was to make it easy for encapsulation:

class FooSelector {
  public function byId($id): array { /* select by Id */ }
  class AsAdmin extends FooSelector {
    public function byId($id): array { /* select by Id */ }
  }
}

$selector =3D $isAdmin ? new FooSelector\AsAdmin : new FooSelector;

But where it really starts to get useful is when you can rewrite a retur=
n by array, into a simple object:

class FooSelector {
  class Foo(int $id, string $bar);

  public function byId($id): Foo { }
}

When working in established code, we very rarely write new classes when =
compared to greenfield systems, where you have to write every new class =
(data objects, services, controllers, repositories, etc). In greenfield =
php projects, you often reach for an array until you need to create a pr=
oper class. Instead of reaching for an array, or writing out an entire f=
ile + boilerplate class, you can just write a short, tightly scoped clas=
s... much like we used to do back before PSR-4. If you recall back then,=
 we'd often put it in the same file because we always knew that FooSelec=
tor would always be included before you could get a Foo. (and yeah, it w=
as a time bomb; it was only a matter of time before someone would create=
 a Foo before they created a FooSelector and it would crash)

class Foo { /* */ }

class FooSelector { /* */ }

If you ever wanted to migrate it to a proper class, you'd just create a =
folder (FooSelector) and copy/paste the class into a new file and keep P=
SR-4 working just fine. In other words, trying to create a FooSelector\F=
oo when Foo was nested, would properly autoload the correct file.

Nested classes v2 won't include visibility. I think that just complicate=
d things too much.

But yes, in established code bases, they probably don't make as much sen=
se, but that was the main problem I was trying to solve: the annoyance o=
f choosing between an array -- or the boilerplate of creating a new clas=
s just to hold a few fields.

>=20
> On the other hand, we can see from constructor property promotion that=
 these little syntax sugar can be such a massive improvement to cognitiv=
e load, readability, writability, etc. I would really love to have somet=
hing much like this RFC even if at first I need to do it as a one-line-p=
er-file. To me, the more interesting chicken-egg problem to address is w=
hether PHP needs to provide some change to symbols, namespaces, autoload=
er or if the community needs to expand PSR-4 in a way that allow us to n=
ot reject this RFC on the basis of "PSR-4 will drastically limit syntax =
sugar improvements".
>=20
> --
> Marco Deleu

I'd also love to see this get implemented and I've offered to help as mu=
ch as I can.

=E2=80=94 Rob
--a3226ad1db4342909824fb3cc03cb119
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Wed, Jul =
16, 2025, at 17:44, Deleu wrote:</div><blockquote type=3D"cite" id=3D"qt=
" style=3D""><div dir=3D"ltr"><div dir=3D"ltr"><br></div><div><br></div>=
<div class=3D"qt-gmail_quote qt-gmail_quote_container"><div dir=3D"ltr" =
class=3D"qt-gmail_attr">On Wed, Jul 16, 2025 at 3:49=E2=80=AFAM Rob Land=
ers &lt;rob@bottled.codes&gt; wrote:</div><blockquote class=3D"qt-gmail_=
quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin=
-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-co=
lor:rgb(204, 204, 204);padding-left:1ex;"><div><u></u><br></div><div><di=
v><br></div><div>Why I haven't proposed it as a separate RFC: with PSR-4=
 being so popular, nobody is going to write one-line files to take advan=
tage of this. Thus, when I was going to revisit nested classes later thi=
s year (after all the release shenanigans and some personal issues), I w=
as planning to add this feature to the nested class v2 RFC (again). A lo=
t of feedback I got on nested classes was "when would I use this?" -- an=
d I suspect that 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 cla=
sses create a chicken-and-egg problem. They only really make sense toget=
her; at least with our current coding conventions and standards. It will=
 create a longer discussion period, but that's fine, IMHO.</div><div><br=
></div><div>If you'd like to continue with this RFC, I'd love to discuss=
 it further with you and help you out. I believe it is a bit more than "=
just" syntax sugar, but I'd have to dig out my records implementation.</=
div><div><br></div><div id=3D"qt-m_1192997838909693588sig121229152">=E2=80=
=94 Rob</div></div></blockquote></div><div><br></div><div>I remember PHP=
 from ~2000's and PSR-4 and Composer were probably one of the biggest im=
provements to the ecosystem. However, I feel like a "2.0" version is lon=
g overdue. I have participated in some internals discussions that point =
out a fact from the other direction: PHP makes no imposition about file =
structure. 1-class-per-file is strictly a PSR-4 implementation of a cust=
om autoloader which we have gotten used to for so long. I would really l=
ove to be able to declare small related classes/interfaces in a single f=
ile much like we can do with Typescript, but the current state of PHP "r=
egister your autoloader however you would like it" vs the current state =
of the community "PSR-4 is THE standard", we end up between a rock and a=
 hard place. I don't particularly enjoy nested classes and how the synta=
x and its contexts get involved. Sure it would be nice to have private c=
lasses, but it gets quite cumbersome to have to do it while nesting clas=
ses within classes.</div></div></blockquote><div><br></div><div>I won't =
comment on the composer stuff or autoloading for that matter. But to you=
r point about nested classes -- well, the entire point of nested classes=
 was to make it easy for encapsulation:</div><div><br></div><div>class F=
ooSelector {</div><div>&nbsp; public function byId($id): array { /* sele=
ct by Id */ }</div><div>&nbsp; class AsAdmin extends FooSelector {</div>=
<div>&nbsp; &nbsp; public function byId($id): array { /* select by Id */=
 }</div><div>&nbsp; }</div><div>}</div><div><br></div><div>$selector =3D=
 $isAdmin ? new FooSelector\AsAdmin : new FooSelector;</div><div><br></d=
iv><div>But where it really starts to get useful is when you can rewrite=
 a return by array, into a simple object:</div><div><br></div><div>class=
 FooSelector {</div><div>&nbsp; class Foo(int $id, string $bar);</div><d=
iv><br></div><div>&nbsp; public function byId($id): Foo { }</div><div>}<=
/div><div><br></div><div>When working in established code, we very rarel=
y write new classes when compared to greenfield systems, where you have =
to write every new class (data objects, services, controllers, repositor=
ies, etc). In greenfield php projects, you often reach for an array unti=
l you need to create a proper class. Instead of reaching for an array, o=
r writing out an entire file + boilerplate class, you can just write a s=
hort, tightly scoped class... much like we used to do back before PSR-4.=
 If you recall back then, we'd often put it in the same file because we =
always knew that FooSelector would always be included before you could g=
et a Foo. (and yeah, it was a time bomb; it was only a matter of time be=
fore someone would create a Foo before they created a FooSelector and it=
 would crash)</div><div><br></div><div>class Foo { /* */ }</div><div><br=
></div><div>class FooSelector { /* */ }</div><div><br></div><div>If you =
ever wanted to migrate it to a proper class, you'd just create a folder =
(FooSelector) and copy/paste the class into a new file and keep PSR-4 wo=
rking just fine. In other words, trying to create a FooSelector\Foo when=
 Foo was nested, would properly autoload the correct file.</div><div><br=
></div><div>Nested classes v2 won't include visibility. I think that jus=
t complicated things too much.</div><div><br></div><div>But yes, in esta=
blished code bases, they probably don't make as much sense, but that was=
 the main problem I was trying to solve: the annoyance of choosing betwe=
en an array -- or the boilerplate of creating a new class just to hold a=
 few fields.</div><div><br></div><blockquote type=3D"cite" id=3D"qt" sty=
le=3D""><div dir=3D"ltr"><div><br></div><div>On the other hand, we can s=
ee from constructor property promotion that these little syntax sugar ca=
n be such a massive improvement to cognitive load, readability, writabil=
ity, etc. I would really love to have something much like this RFC even =
if at first I need to do it as a one-line-per-file. To me, the more inte=
resting chicken-egg problem to address is whether PHP needs to provide s=
ome change to symbols, namespaces, autoloader or if the community needs =
to expand PSR-4 in a way that allow us to not reject this RFC on the bas=
is of "PSR-4 will drastically limit syntax sugar improvements".</div><di=
v><br></div><div><span class=3D"qt-gmail_signature_prefix">--</span></di=
v><div dir=3D"ltr" class=3D"qt-gmail_signature"><div dir=3D"ltr"><div di=
r=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D=
"ltr"><div dir=3D"ltr">Marco Deleu</div></div></div></div></div></div></=
div></div></div></blockquote><div><br></div><div>I'd also love to see th=
is get implemented and I've offered to help as much as I can.</div><div>=
<br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--a3226ad1db4342909824fb3cc03cb119--