Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126742
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 13 Mar 2025 22:23:39 +0100
To: internals@lists.php.net
Message-ID: <0543a041-4d31-415e-be30-b8d34e29ee0f@app.fastmail.com>
In-Reply-To: 
 <CAPyj-LBQMxgyD98s=29gPt0GnX-c8=HHMcaFzUC8smWSFP8YqQ@mail.gmail.com>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com>
 <2935d0e2-ddc4-447c-ab37-c9b7337b8b60@app.fastmail.com>
 <0d94bf183543ee9948fcd31337198438@bastelstu.be>
 <CAPyj-LCWcVTwJGn9fViq+gZnEhbSZ_QKGTRUCmznWb25AR0XWQ@mail.gmail.com>
 <ebf1997e-c93e-4b2a-b203-7c67860689b0@app.fastmail.com>
 <CAPyj-LBQMxgyD98s=29gPt0GnX-c8=HHMcaFzUC8smWSFP8YqQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: RFC: short and inner classes
Content-Type: multipart/alternative;
 boundary=920afeb387aa4dfb941e0ae5827c6b8c
From: rob@bottled.codes ("Rob Landers")

--920afeb387aa4dfb941e0ae5827c6b8c
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 13, 2025, at 21:41, Ilija Tovilo wrote:
> Hi Rob
>=20
> On Thu, Mar 13, 2025 at 1:57=E2=80=AFPM Rob Landers <rob@bottled.codes=
> wrote:
> >
> > > the proposal is
> > > currently quite complex.
> >
> > Most of this is just describing how classes work already and going i=
n-depth on where there may be confusion -- there are no significant chan=
ges to how classes actually work. The actual changes to the engine are b=
asically just visibility rules, some syntax changes (to allow nesting `c=
lass` inside another class), and handling the new operator. The hard par=
t is explaining how classes work, because they don't really have a defin=
ed behavior. In other words, I cannot just say "the way this works doesn=
't change anything."
>=20
> Well, you cut out the examples I gave:

Ahh, ok. FWIW, I only cut out your examples to shorten the email. But I =
see what you mean here. I think I can word the RFC in such a way as to m=
ake it so I don't have to specify how classes work along with how inner =
classes work... I'll have to think about it. Maybe I can just explain mo=
re about how it actually works? I'm not sure. I'll probably look at the =
enums RFC to get a better idea of how to do this.

For example, I can explain that an inner class is basically a class with=
 a special name and special scopes attached. Then I can simply explain h=
ow these special scopes interact with the rest of the language. Then I c=
an get around defining class-like behaviors, and it may even be easier t=
o reason about.

> > It has a custom operator, it deals with shadowing, LSP, runtime reso=
lution and more, in addition to visibility which is the actual goal. Tho=
se are unrelated to existing behavior, they are introduced in the propos=
al.
>=20
> * The custom operator and runtime resolution is not something that
> technically needs to be there. The name of class Foo { class Bar {} }
> could simply be Foo\Bar. I've mentioned before that this does not work
> with PSR-4, but there's no reason it can't work with autoloading at
> all. An extended autoloading spec could recursively search
> Foo/Bar/Baz.php, then Foo/Bar.php, and so forth. Given this happens
> only when loading the class, and nesting would usually be limited in
> quantity and amount, that seems like a reasonable solution, and
> Composers optimized autoloader could avoid it entirely. This would
> also solve the same issue for sealed classes, assuming they're named
> in a similar fashion.

I disagree completely. If you recall, last year, I tried to pass functio=
n autoloading (which would have helped with records) and people really, =
really, really didn't want to have to change how autoloading worked (and=
 I'm not talking about the list -- I mean projects). So, suggesting a ch=
ange to autoloading is probably a non-starter.

That being said, I don't hate it either.

>=20
> * By shadowing I referred to static:>MyClass. This makes it more
> modular, but it's also another layer of complexity and indirection.
> You haven't really provided a reasoning and examples of how this could
> be used. It's also not clear if this can be prevented. The inner class
> can be marked as final, but that wouldn't stop you from shadowing the
> inner class without extending it. Similarly, static:>MyClass would
> have no type guarantees, given that it can be shadowed by any classes,
> not just classes that are compatible.
>=20
> class Outer {
>     protected class Inner {
>         public static function innerTest() {}
>     }
>=20
>     public static function outerTest() {
>         static:>Inner::innerTest();
>     }
> }
>=20
> class OuterV2 extends Outer {
>     protected class Inner {} // This breaks outerTest()
> }

`static` is expressly forbidden with inner classes after Tim pointed out=
 that it basically breaks LSP. It doesn't, technically, but it makes it =
hard to reason about for the exact example you gave.

One thing worth pointing out here, though, is that in your example you h=
ave Outer:>Inner and OuterV2:>Inner. These are two completely distinct c=
lasses. They are not related to each other at all.=20

>=20
> * LSP issues have been mentioned before. You can use self:>Inner in
> method signatures even if the inner classes are private. The method
> could be called from sub-classes, but they couldn't ever override it,
> since there's no way to satisfy the parent signature. This makes it
> implicitly final. Not technically a problem, just odd.

This is not the case any more. If you have a private inner class, you ca=
nnot use it as a type declaration on a protected/public method, property=
, or static member. A private class can still be returned and passed aro=
und once instantiated, and it can implement an interface/base class (or =
not). This is very similar to C# or Java.

For example, this is ok:

interface Shape {}

class ShapeFactory {
  private class Rect implements Shape {}

  public function makeRect()): Shape { return new ShapeFactory:>Rect(); }
}

But this is not:

class ShapeFactory {
  private class Rect {}

  // Private inner class ShapeFactory::Rect cannot be used as a return t=
ype for public methods
  public function makeRect()): ShapeFactory:>Rect { return new ShapeFact=
ory:>Rect(); }
}

> As mentioned, maybe there are additional use-cases this complexity can
> cover, but the RFC doesn't give many examples. If the primary reason
> for this complexity is just visibility, then I don't think this is the
> simplest and best way in which that goal could be achieved.

I'll add some more realistic examples to the RFC.

>=20
> > > They might
> > > still be ok if they are extremely simple
> >
> > And now you can understand why they WERE just simple classes (short =
classes). So, you can see why I originally bundled them together because=
 of this EXACT argument. :sigh:
>=20
> The arguments above are not limited to complex classes. Simple classes
> would apply to.



>=20
> * The :> operator is still something new that I don't believe needs to=
 be there.
> * Shadowing simple classes can still cause incompatibilities between
> constructors.
> * The LSP issue applies.
> * As soon as we try to add support for complex classes, we'll run into
> the same questions again. Thinking ahead is always worth it, to
> prevent us from running into issues later. Doesn't mean everything
> needs to land at the same time ofc.
>=20
> Ilija
>=20

=E2=80=94 Rob
--920afeb387aa4dfb941e0ae5827c6b8c
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 Thu, Mar 13,=
 2025, at 21:41, Ilija Tovilo wrote:<br></div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>Hi Rob<br></div><div><br></div><div>On Thu, Ma=
r 13, 2025 at 1:57=E2=80=AFPM Rob Landers &lt;<a href=3D"mailto:rob@bott=
led.codes">rob@bottled.codes</a>&gt; wrote:<br></div><div>&gt;<br></div>=
<div>&gt; &gt; the proposal is<br></div><div>&gt; &gt; currently quite c=
omplex.<br></div><div>&gt;<br></div><div>&gt; Most of this is just descr=
ibing how classes work already and going in-depth on where there may be =
confusion -- there are no significant changes to how classes actually wo=
rk. The actual changes to the engine are basically just visibility rules=
, some syntax changes (to allow nesting `class` inside another class), a=
nd handling the new operator. The hard part is explaining how classes wo=
rk, because they don't really have a defined behavior. In other words, I=
 cannot just say "the way this works doesn't change anything."<br></div>=
<div><br></div><div>Well, you cut out the examples I gave:<br></div></bl=
ockquote><div><br></div><div><div>Ahh, ok. FWIW, I only cut out your exa=
mples to shorten the email. But I see what you mean here. I think I can =
word the RFC in such a way as to make it so I don't have to specify how =
classes work along with how inner classes work... I'll have to think abo=
ut it. Maybe I can just explain more about how it actually works? I'm no=
t sure. I'll probably look at the enums RFC to get a better idea of how =
to do this.<br></div><div><br></div><div>For example, I can explain that=
 an inner class is basically a class with a special name and special sco=
pes attached. Then I can simply explain how these special scopes interac=
t with the rest of the language. Then I can get around defining class-li=
ke behaviors, and it may even be easier to reason about.</div><div><br><=
/div></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>&gt; It h=
as a custom operator, it deals with shadowing, LSP, runtime resolution a=
nd more, in addition to visibility which is the actual goal. Those are u=
nrelated to existing behavior, they are introduced in the proposal.<br><=
/div><div><br></div><div>* The custom operator and runtime resolution is=
 not something that<br></div><div>technically needs to be there. The nam=
e of class Foo { class Bar {} }<br></div><div>could simply be Foo\Bar. I=
've mentioned before that this does not work<br></div><div>with PSR-4, b=
ut there's no reason it can't work with autoloading at<br></div><div>all=
. An extended autoloading spec could recursively search<br></div><div>Fo=
o/Bar/Baz.php, then Foo/Bar.php, and so forth. Given this happens<br></d=
iv><div>only when loading the class, and nesting would usually be limite=
d in<br></div><div>quantity and amount, that seems like a reasonable sol=
ution, and<br></div><div>Composers optimized autoloader could avoid it e=
ntirely. This would<br></div><div>also solve the same issue for sealed c=
lasses, assuming they're named<br></div><div>in a similar fashion.<br></=
div></blockquote><div><br></div><div>I disagree completely. If you recal=
l, last year, I tried to pass function autoloading (which would have hel=
ped with records) and people really, really, really didn't want to have =
to change how autoloading worked (and I'm not talking about the list -- =
I mean projects). So, suggesting a change to autoloading is probably a n=
on-starter.<br></div><div><br></div><div>That being said, I don't hate i=
t either.<br></div><div><br></div><blockquote type=3D"cite" id=3D"qt" st=
yle=3D""><div><br></div><div>* By shadowing I referred to static:&gt;MyC=
lass. This makes it more<br></div><div>modular, but it's also another la=
yer of complexity and indirection.<br></div><div>You haven't really prov=
ided a reasoning and examples of how this could<br></div><div>be used. I=
t's also not clear if this can be prevented. The inner class<br></div><d=
iv>can be marked as final, but that wouldn't stop you from shadowing the=
<br></div><div>inner class without extending it. Similarly, static:&gt;M=
yClass would<br></div><div>have no type guarantees, given that it can be=
 shadowed by any classes,<br></div><div>not just classes that are compat=
ible.<br></div><div><br></div><div>class Outer {<br></div><div>&nbsp;&nb=
sp;&nbsp; protected class Inner {<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; public static function innerTest() {}<br></div><div>&=
nbsp;&nbsp;&nbsp; }<br></div><div><br></div><div>&nbsp;&nbsp;&nbsp; publ=
ic static function outerTest() {<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; static:&gt;Inner::innerTest();<br></div><div>&nbsp;&nb=
sp;&nbsp; }<br></div><div>}<br></div><div><br></div><div>class OuterV2 e=
xtends Outer {<br></div><div>&nbsp;&nbsp;&nbsp; protected class Inner {}=
 // This breaks outerTest()<br></div><div>}<br></div></blockquote><div><=
br></div><div>`static` is expressly forbidden with inner classes after T=
im pointed out that it basically breaks LSP. It doesn't, technically, bu=
t it makes it hard to reason about for the exact example you gave.<br></=
div><div><br></div><div>One thing worth pointing out here, though, is th=
at in your example you have Outer:&gt;Inner and OuterV2:&gt;Inner. These=
 are two completely distinct classes. They are not related to each other=
 at all.&nbsp;<br></div><div><br></div><blockquote type=3D"cite" id=3D"q=
t" style=3D""><div><br></div><div>* LSP issues have been mentioned befor=
e. You can use self:&gt;Inner in<br></div><div>method signatures even if=
 the inner classes are private. The method<br></div><div>could be called=
 from sub-classes, but they couldn't ever override it,<br></div><div>sin=
ce there's no way to satisfy the parent signature. This makes it<br></di=
v><div>implicitly final. Not technically a problem, just odd.<br></div><=
/blockquote><div><br></div><div>This is not the case any more. If you ha=
ve a private inner class, you cannot use it as a type declaration on a p=
rotected/public method, property, or static member. A private class can =
still be returned and passed around once instantiated, and it can implem=
ent an interface/base class (or not). This is very similar to C# or Java=
.<br></div><div><br></div><div>For example, this is ok:<br></div><div><b=
r></div><div>interface Shape {}<br></div><div><br></div><div>class Shape=
Factory {<br></div><div>&nbsp; private class Rect implements Shape {}<br=
></div><div><br></div><div>&nbsp; public function makeRect()): Shape { r=
eturn new ShapeFactory:&gt;Rect(); }<br></div><div>}<br></div><div><br><=
/div><div>But this is not:<br></div><div><br></div><div>class ShapeFacto=
ry {<br></div><div>&nbsp; private class Rect {}<br></div><div><br></div>=
<div>&nbsp; //&nbsp;Private inner class ShapeFactory::Rect cannot be use=
d as a return type for public methods<br></div><div>&nbsp; public functi=
on makeRect()): ShapeFactory:&gt;Rect { return new ShapeFactory:&gt;Rect=
(); }<br></div><div>}<br></div><div><br></div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>As mentioned, maybe there are additional use-c=
ases this complexity can<br></div><div>cover, but the RFC doesn't give m=
any examples. If the primary reason<br></div><div>for this complexity is=
 just visibility, then I don't think this is the<br></div><div>simplest =
and best way in which that goal could be achieved.<br></div></blockquote=
><div><br></div><div>I'll add some more realistic examples to the RFC.</=
div><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><=
br></div><div>&gt; &gt; They might<br></div><div>&gt; &gt; still be ok i=
f they are extremely simple<br></div><div>&gt;<br></div><div>&gt; And no=
w you can understand why they WERE just simple classes (short classes). =
So, you can see why I originally bundled them together because of this E=
XACT argument. :sigh:<br></div><div><br></div><div>The arguments above a=
re not limited to complex classes. Simple classes<br></div><div>would ap=
ply to.<br></div></blockquote><div><br></div><div><br></div><div><br></d=
iv><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div>* =
The :&gt; operator is still something new that I don't believe needs to =
be there.<br></div><div>* Shadowing simple classes can still cause incom=
patibilities between<br></div><div>constructors.<br></div><div>* The LSP=
 issue applies.<br></div><div>* As soon as we try to add support for com=
plex classes, we'll run into<br></div><div>the same questions again. Thi=
nking ahead is always worth it, to<br></div><div>prevent us from running=
 into issues later. Doesn't mean everything<br></div><div>needs to land =
at the same time ofc.<br></div><div><br></div><div>Ilija<br></div><div><=
br></div></blockquote><div><br></div><div id=3D"sig121229152">=E2=80=94 =
Rob<br></div></body></html>
--920afeb387aa4dfb941e0ae5827c6b8c--