Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126798
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 17 Mar 2025 08:11:23 +0100
To: internals@lists.php.net
Message-ID: <8bbb484b-96a3-4a3e-881e-2c47d7f433b9@app.fastmail.com>
In-Reply-To: <0F1E4400-5E26-4E39-88B9-ABD7ABBAEBC4@rwec.co.uk>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com>
 <AM8P250MB01709D7FC3E4FDF07E8995C2E2D22@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <4abd7008-ae33-46fe-8bbd-7c99f7c48158@app.fastmail.com>
 <0F1E4400-5E26-4E39-88B9-ABD7ABBAEBC4@rwec.co.uk>
Subject: Re: [PHP-DEV] RFC: short and inner classes
Content-Type: multipart/alternative;
 boundary=e29859c7b6884f14b34fc26fc9744f87
From: rob@bottled.codes ("Rob Landers")

--e29859c7b6884f14b34fc26fc9744f87
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sat, Mar 15, 2025, at 12:53, Rowan Tommins [IMSoP] wrote:
>=20
>=20
> On 14 March 2025 23:37:08 GMT, Rob Landers <rob@bottled.codes> wrote:
> >I could get behind `::`, but I feel that it introduces human ambiguit=
y. I don't believe it would introduce compiler ambiguity, but as a human=
, I have to hope the programmers are using a style that makes it obvious=
 what are inner classes and what are constants/methods.
>=20
> As far as I can see, all four languages I looked up last night (Java, =
C#, Swift, Kotlin) use the same syntax for accessing a nested type as fo=
r accessing a property or method, so we'd be following the crowd to use =
"::"
>=20
> That said, I think they all also use that same syntax for namespace (o=
r equivalent) lookups, so the same argument can be made for "\". (Why PH=
P separates those isn't entirely clear to me.)
>=20
> Having some new syntax makes them feel more "exotic" to me. The C# and=
 Swift docs give the impression that nesting types is "just something th=
at can happen", rather than a whole new language concept to learn.
>=20
> Java's "inner classes" are something different, and I think we should =
avoid using that term.
>=20
>=20
>=20
> > Furthermore, I'm relatively certain this approach can be slightly mo=
dified to support "namespace private/protected" classes, in general. So,=
 that will also possibly be a follow-up RFC and having them mixed up wil=
l complicate things. In any case, I am not a fan of using the namespace =
separator here.
>=20
> To me namespace, module, or file visibility seem like much more natura=
l additions to the language, and to solve most of the same problems as n=
esting types.
>=20
> I guess a public nested class is a bit like a "friend class"? In that =
it has special access to its surrounding class, but otherwise might as w=
ell just be sharing a namespace with it. But it's also necessarily in th=
e same file, so marking those members "file private" rather than "privat=
e" would also allow that.
>=20
> A private nested class can only be explicitly mentioned within that na=
rrow context, which again feels very much equivalent to "file private".
>=20
>=20
> > $user =3D new User:>Builder("Rob")->withEmail("rob@bottled.codes")->=
build();
> >
> > The user builder is intrinsically tied to the User class itself, it =
isn't just a namespace. The user builder shares scope with the user clas=
s and is able to be the only way to construct a user (barring reflection=
).
>=20
> If we had either file or namespace visibility, exactly the same thing =
could be achieved with those, and would look like this:=20
>=20
> $user =3D new User\Builder("Rob")->withEmail("rob@bottled.codes")->bui=
ld();
>=20
> The "User" class would have a "file private" or "namespace private" co=
nstructor, callable from the "User\Builder" class but not elsewhere; the=
 build() method would return the "User" instance.
>=20
>=20
>=20
> I think I'm coming to the conclusion that we should use backslash: nes=
ted types can be viewed as a shorthand way of having a class and namespa=
ce with the same name, plus applying some visibility rules to that names=
pace.
>=20
> Rowan Tommins
> [IMSoP]
>=20

I don=E2=80=99t think `\` is viable. If we used slash it would complicat=
e autoloading and be impossible to differentiate between=20

namespace Outer;

class Inner {}

And

class Outer {
  class Inner {}
}

These would both resolve to the same class name for Outer\Inner. Which o=
ne it resolves to would depend on how you implement autoloading (which m=
ay be desirable for BC reasons). Then there becomes the question of eith=
er letting user-land implement the autoloading changes, or have php walk=
 =E2=80=9Cup=E2=80=9D the namespace chain in the hopes it implements an =
inner class.

So, maybe, it could be useful to use `\` but in the long run, I=E2=80=99=
m not sure it makes sense.=20

=E2=80=94 Rob
--e29859c7b6884f14b34fc26fc9744f87
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><br></div><div>=
<br></div><div>On Sat, Mar 15, 2025, at 12:53, Rowan Tommins [IMSoP] wro=
te:<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></d=
iv><div><br></div><div>On 14 March 2025 23:37:08 GMT, Rob Landers &lt;<a=
 href=3D"mailto:rob@bottled.codes">rob@bottled.codes</a>&gt; wrote:<br><=
/div><div>&gt;I could get behind `::`, but I feel that it introduces hum=
an ambiguity. I don't believe it would introduce compiler ambiguity, but=
 as a human, I have to hope the programmers are using a style that makes=
 it obvious what are inner classes and what are constants/methods.<br></=
div><div><br></div><div>As far as I can see, all four languages I looked=
 up last night (Java, C#, Swift, Kotlin) use the same syntax for accessi=
ng a nested type as for accessing a property or method, so we'd be follo=
wing the crowd to use "::"<br></div><div><br></div><div>That said, I thi=
nk they all also use that same syntax for namespace (or equivalent) look=
ups, so the same argument can be made for "\". (Why PHP separates those =
isn't entirely clear to me.)<br></div><div><br></div><div>Having some ne=
w syntax makes them feel more "exotic" to me. The C# and Swift docs give=
 the impression that nesting types is "just something that can happen", =
rather than a whole new language concept to learn.<br></div><div><br></d=
iv><div>Java's "inner classes" are something different, and I think we s=
hould avoid using that term.<br></div><div><br></div><div><br></div><div=
><br></div><div>&gt; Furthermore, I'm relatively certain this approach c=
an be slightly modified to support "namespace private/protected" classes=
, in general. So, that will also possibly be a follow-up RFC and having =
them mixed up will complicate things. In any case, I am not a fan of usi=
ng the namespace separator here.<br></div><div><br></div><div>To me name=
space, module, or file visibility seem like much more natural additions =
to the language, and to solve most of the same problems as nesting types=
.<br></div><div><br></div><div>I guess a public nested class is a bit li=
ke a "friend class"? In that it has special access to its surrounding cl=
ass, but otherwise might as well just be sharing a namespace with it. Bu=
t it's also necessarily in the same file, so marking those members "file=
 private" rather than "private" would also allow that.<br></div><div><br=
></div><div>A private nested class can only be explicitly mentioned with=
in that narrow context, which again feels very much equivalent to "file =
private".<br></div><div><br></div><div><br></div><div>&gt; $user =3D new=
 User:&gt;Builder("Rob")-&gt;withEmail("<a href=3D"mailto:rob@bottled.co=
des">rob@bottled.codes</a>")-&gt;build();<br></div><div>&gt;<br></div><d=
iv>&gt; The user builder is intrinsically tied to the User class itself,=
 it isn't just a namespace. The user builder shares scope with the user =
class and is able to be the only way to construct a user (barring reflec=
tion).<br></div><div><br></div><div>If we had either file or namespace v=
isibility, exactly the same thing could be achieved with those, and woul=
d look like this:&nbsp;<br></div><div><br></div><div>$user =3D new User\=
Builder("Rob")-&gt;withEmail("<a href=3D"mailto:rob@bottled.codes">rob@b=
ottled.codes</a>")-&gt;build();<br></div><div><br></div><div>The "User" =
class would have a "file private" or "namespace private" constructor, ca=
llable from the "User\Builder" class but not elsewhere; the build() meth=
od would return the "User" instance.<br></div><div><br></div><div><br></=
div><div><br></div><div>I think I'm coming to the conclusion that we sho=
uld use backslash: nested types can be viewed as a shorthand way of havi=
ng a class and namespace with the same name, plus applying some visibili=
ty rules to that namespace.<br></div><div><br></div><div>Rowan Tommins<b=
r></div><div>[IMSoP]<br></div><div><br></div></blockquote><div><br></div=
><div>I don=E2=80=99t think `\` is viable. If we used slash it would com=
plicate autoloading and be impossible to differentiate between&nbsp;<br>=
</div><div><br></div><div>namespace Outer;<br></div><div><br></div><div>=
class Inner {}<br></div><div><br></div><div>And<br></div><div><br></div>=
<div>class Outer {<br></div><div>&nbsp; class Inner {}<br></div><div>}<b=
r></div><div><br></div><div>These would both resolve to the same class n=
ame for Outer\Inner. Which one it resolves to would depend on how you im=
plement autoloading (which may be desirable for BC reasons). Then there =
becomes the question of either letting user-land implement the autoloadi=
ng changes, or have php walk =E2=80=9Cup=E2=80=9D the namespace chain in=
 the hopes it implements an inner class.<br></div><div><br></div><div>So=
, maybe, it could be useful to use `\` but in the long run, I=E2=80=99m =
not sure it makes sense.&nbsp;</div><div><br></div><div id=3D"sig1212291=
52">=E2=80=94 Rob<br></div></body></html>
--e29859c7b6884f14b34fc26fc9744f87--