Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126807
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 17 Mar 2025 17:53:26 +0100
To: "fennic log" <fenniclog@gmail.com>
Cc: internals@lists.php.net
Message-ID: <3e4ba7ea-a154-452d-abfc-05ef1322fade@app.fastmail.com>
In-Reply-To: 
 <CAO__Xv4END_NsATOGSnCArGuP_UmSpMxSMsSNPsQZnLooOWTsQ@mail.gmail.com>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com>
 <CAO__Xv4END_NsATOGSnCArGuP_UmSpMxSMsSNPsQZnLooOWTsQ@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC: short and inner classes
Content-Type: multipart/alternative;
 boundary=e4c60d741a194b3ea031b907cc939365
From: rob@bottled.codes ("Rob Landers")

--e4c60d741a194b3ea031b907cc939365
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 17, 2025, at 16:30, fennic log wrote:
>=20
> On Wed, 5 Mar 2025 at 23:14, Rob Landers <rob@bottled.codes> wrote:
>> __
>> Hello PHP Internals,
>>=20
>> I'd like to introduce my RFC for discussion: https://wiki.php.net/rfc=
/short-and-inner-classes
>>=20
>> This RFC defines a short class syntax as well as the ability to nest =
classes inside another class. This introduces an unprecedented amount of=
 control, flexibility, and expressiveness over how objects are used and =
instantiated in PHP. There is a PR (https://github.com/php/php-src/pull/=
17895) that implements this functionality -- all test failures are relat=
ed to different/new/incorrect error messages being generated. However, t=
he core functionality exists to take for a test ride.
>>=20
>> So, what do I mean by "unprecedented amount of control"? With this ch=
ange, you can declare an inner class as private or protected, preventing=
 its usage outside of the outer class:
>>=20
>> class User {
>>   private class Id {}
>>=20
>>   public function __construct(public self::Id $id) {}
>> }
>>=20
>> In the above example, the class `User` is impossible to construct eve=
n though it has a public constructor (except through reflection) because=
 User::Id is private; User::Id cannot be instantiated, used as a type hi=
nt, or even via `instanceof` outside of the User class itself. This exam=
ple isn't practical but demonstrates something that is nearly impossible=
 in previous versions of PHP, where all classes are essentially publicly=
 accessible from anywhere within the codebase.
>>=20
>> As a number of inner classes will probably be used as DTOs, the RFC i=
ntroduces a "short syntax" for declaring classes, which enhances express=
iveness, even allowing the usage of traits, all in a single line:
>>=20
>> // declare a readonly Point, that implements Vector2 and uses the Evo=
lvable trait
>> readonly class Point(public int $x, public int $y) implements Vector2=
 use Evolvable;
>>=20
>> When combined with inner classes, it looks something like this:
>>=20
>> class Pixel {
>>   public readonly class Point(public int $x, public int $y) implement=
s Vector2 use Evolvable;
>> }
>>=20
>> // Create a new pixel point with property $x and $y set to 0
>> $p =3D new Pixel::Point(0, 0);
>>=20
>> There are far more details in the RFC itself, so please check it out.=
 I'm quite excited to hear your thoughts!
>>=20
>> =E2=80=94 Rob
>>=20
>> PS. I know I tend to rush into things, but I want to make it clear th=
at I'm not rushing this -- I've learned from my mistakes (thank you to t=
hose who have given me advice). I'm going to do this right.
>=20
> I have read and reread this RFC, and I am struggling to see=20
>=20
> 1. What problem does this solve that anonymous classes <https://www.ph=
p.net/manual/en/language.oop5.anonymous.php> do not?

Thank you for asking this question. :) Anonymous classes can be useful t=
o "hack your way around" the problem that inner (nested?) classes solve.=
 Anonymous classes are inline, leading to complex/long functions that wo=
uld do nothing but define a class. Anonymous classes can (could?) be hac=
ked to allow for reuse (extending), but only exist where they are define=
d. An inner class can be extended and reused just fine. Finally, nested =
classes allow for more readable code without sacrificing encapsulation.

> 2. As with any syntax change and new operator there needs to be very c=
areful consideration, do we need a new operation, or could `::` if the p=
arent is static or `->` if the class is initialized?

There's quite a long thread already about this very topic. That being sa=
id, the inner class has no bearing on whether the outer class is instant=
iated or not. Originally, I used `::` as the separator, but it seems the=
re are some good arguments for `\`, so we will see.

> 3. The idea that extending the parent class doesnt no inherit the chil=
d classes doesnt make sense to me.=20
> As then if you extend a parent class and call a function of that class=
 which could rely on the existence of an inner class, I can see a lot of=
 headaches caused by this exact scenario.
> As a developer, if I extend a class, I expect the entire dependance of=
 that class to be inherited, otherwise the extending class won't work.=20

I'm not sure what you mean. When you inherit a class, you do not necessa=
rily inherit everything from its superclass. You are free to override it=
 however you want. Since we are defining "types" in the sense of PHP, we=
 cannot merely inherit a "type", otherwise we would cause all kinds of i=
ssues with LSP. This is specifically why inheritance works the way it do=
es in this RFC and why `static::` is forbidden.=20

=E2=80=94 Rob
--e4c60d741a194b3ea031b907cc939365
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Mon, Mar 17,=
 2025, at 16:30, fennic log wrote:<br></div><blockquote type=3D"cite" id=
=3D"qt" style=3D""><div dir=3D"ltr"><div dir=3D"ltr"><br></div><div clas=
s=3D"qt-gmail_quote qt-gmail_quote_container"><div dir=3D"ltr" class=3D"=
qt-gmail_attr">On Wed, 5 Mar 2025 at 23:14, Rob Landers &lt;rob@bottled.=
codes&gt; wrote:<br></div><blockquote class=3D"qt-gmail_quote" style=3D"=
margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;bord=
er-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204=
, 204);padding-left:1ex;"><div class=3D"qt-msg-8043171373763607374"><div=
><u></u><br></div><div><div>Hello PHP Internals,<br></div><div><br></div=
><div>I'd like to introduce my RFC for discussion:&nbsp;<a href=3D"https=
://wiki.php.net/rfc/short-and-inner-classes" target=3D"_blank">https://w=
iki.php.net/rfc/short-and-inner-classes</a><br></div><div><br></div><div=
>This RFC defines a short class syntax as well as the ability to nest cl=
asses inside another class. This introduces an unprecedented amount of c=
ontrol, flexibility, and expressiveness over how objects are used and in=
stantiated in PHP. There is a PR (<a href=3D"https://github.com/php/php-=
src/pull/17895" target=3D"_blank">https://github.com/php/php-src/pull/17=
895</a>) that implements this functionality -- all test failures are rel=
ated to different/new/incorrect error messages being generated. However,=
 the core functionality exists to take for a test ride.<br></div><div><b=
r></div><div>So, what do I mean by "unprecedented amount of control"? Wi=
th this change, you can declare an inner class as private or protected, =
preventing its usage outside of the outer class:<br></div><div><br></div=
><div>class User {<br></div><div>&nbsp; private class Id {}<br></div><di=
v><br></div><div>&nbsp; public function __construct(public self::Id $id)=
 {}<br></div><div>}<br></div><div><br></div><div>In the above example, t=
he class `User` is impossible to construct even though it has a public c=
onstructor (except through reflection) because User::Id is private; User=
::Id cannot be instantiated, used as a type hint, or even via `instanceo=
f` outside of the User class itself. This example isn't practical but de=
monstrates something that is nearly impossible in previous versions of P=
HP, where all classes are essentially publicly accessible from anywhere =
within the codebase.<br></div><div><br></div><div>As a number of inner c=
lasses will probably be used as DTOs, the RFC introduces a "short syntax=
" for declaring classes, which enhances expressiveness, even allowing th=
e usage of traits, all in a single line:<br></div><div><br></div><div>//=
 declare a readonly Point, that implements Vector2 and uses the Evolvabl=
e trait<br></div><div>readonly class Point(public int $x, public int $y)=
 implements Vector2 use Evolvable;<br></div><div><br></div><div>When com=
bined with inner classes, it looks something like this:<br></div><div><b=
r></div><div>class Pixel {<br></div><div>&nbsp; public readonly class Po=
int(public int $x, public int $y) implements Vector2 use Evolvable;<br><=
/div><div>}<br></div><div><br></div><div>// Create a new pixel point wit=
h property $x and $y set to 0<br></div><div>$p =3D new Pixel::Point(0, 0=
);<br></div><div><br></div><div>There are far more details in the RFC it=
self, so please check it out. I'm quite excited to hear your thoughts!<b=
r></div><div><br></div><div id=3D"qt-m_-8043171373763607374sig121229152"=
>=E2=80=94 Rob<br></div><div id=3D"qt-m_-8043171373763607374sig121229152=
"><br></div><div><div>PS. I know I tend to rush into things, but I want =
to make it clear that I'm not rushing this -- I've learned from my mista=
kes (thank you to those who have given me advice). I'm going to do this =
right.<br></div></div></div></div></blockquote><div><br></div><div>I hav=
e read and reread this RFC, and I am struggling to see&nbsp;<br></div><d=
iv><br></div><div>1. What problem does this solve&nbsp;that <a href=3D"h=
ttps://www.php.net/manual/en/language.oop5.anonymous.php">anonymous clas=
ses</a>&nbsp;do not?<br></div></div></div></blockquote><div><br></div><d=
iv>Thank you for asking this question. :) Anonymous classes can be usefu=
l to "hack your way around" the problem that inner (nested?) classes sol=
ve. Anonymous classes are inline, leading to complex/long functions that=
 would do nothing but define a class. Anonymous classes can (could?) be =
hacked to allow for reuse (extending), but only exist where they are def=
ined. An inner class can be extended and reused just fine. Finally, nest=
ed classes allow for more readable code without sacrificing encapsulatio=
n.</div><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><d=
iv dir=3D"ltr"><div class=3D"qt-gmail_quote qt-gmail_quote_container"><d=
iv>2. As with any syntax change and new operator there needs to be very =
careful consideration, do we need a new operation, or could `::` if the =
parent is static or `-&gt;` if the class is initialized?<br></div></div>=
</div></blockquote><div><br></div><div>There's quite a long thread alrea=
dy about this very topic. That being said, the inner class has no bearin=
g on whether the outer class is instantiated or not. Originally, I used =
`::` as the separator, but it seems there are some good arguments for `\=
`, so we will see.</div><div><br></div><blockquote type=3D"cite" id=3D"q=
t" style=3D""><div dir=3D"ltr"><div class=3D"qt-gmail_quote qt-gmail_quo=
te_container"><div>3. The idea that extending the parent class doesnt no=
 inherit the child classes doesnt&nbsp;make sense to me.&nbsp;<br></div>=
<div>As then if you extend a parent class and call a function of that cl=
ass which could rely on the existence of an inner class, I can see a lot=
 of headaches caused by this exact scenario.<br></div><div>As a develope=
r, if I extend a class, I expect the entire dependance of that class to =
be inherited, otherwise the extending class won't work.&nbsp;<br></div><=
/div></div></blockquote><div><br></div><div>I'm not sure what you mean. =
When you inherit a class, you do not necessarily inherit everything from=
 its superclass. You are free to override it however you want. Since we =
are defining "types" in the sense of PHP, we cannot merely inherit a "ty=
pe", otherwise we would cause all kinds of issues with LSP. This is spec=
ifically why inheritance works the way it does in this RFC and why `stat=
ic::` is forbidden.&nbsp;</div><div><br></div><div id=3D"sig121229152">=E2=
=80=94 Rob<br></div></body></html>
--e4c60d741a194b3ea031b907cc939365--