Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126745
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 14 Mar 2025 00:26:03 +0100
To: "Bob Weinand" <bobwei9@hotmail.com>
Cc: internals@lists.php.net, =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Message-ID: <44ccdbea-747d-46ca-97f9-8dd63fe8b55a@app.fastmail.com>
In-Reply-To: 
 <AM8P250MB01707EFDB6113C6902884083E2D32@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com>
 <2935d0e2-ddc4-447c-ab37-c9b7337b8b60@app.fastmail.com>
 <0d94bf183543ee9948fcd31337198438@bastelstu.be>
 <b10ba5b6-8427-4efd-b183-7902b349673f@app.fastmail.com>
 <AM8P250MB01707EFDB6113C6902884083E2D32@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Subject: Re: [PHP-DEV] Re: RFC: short and inner classes
Content-Type: multipart/alternative;
 boundary=34be739e28bc46b19a36711ca385a78b
From: rob@bottled.codes ("Rob Landers")

--34be739e28bc46b19a36711ca385a78b
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Thu, Mar 13, 2025, at 23:26, Bob Weinand wrote:
> Hey Rob,
>=20
> On 13.3.2025 21:46:49, Rob Landers wrote:
>> On Thu, Mar 13, 2025, at 12:01, Tim D=C3=BCsterhus wrote:
>>> Hi
>>>=20
>>> Am 2025-03-12 11:10, schrieb Rob Landers:
>>> > - Accessing inner classes is done via a new token: ":>" instead of=20
>>> > "::".
>>>=20
>>> I don't particularly like that. It is =E2=80=9Cinvented syntax=E2=80=
=9D and I don't=20
>>> think that inner classes are sufficiently valuable to dedicate an en=
tire=20
>>> operator to them that could serve a more useful purpose in the futur=
e.=20
>>> It also got 4 negative points in the rating back when the namespace=20
>>> separator was decided: https://wiki.php.net/rfc/namespaceseparator
>>>=20
>>> Would `\\` (i.e. two backslashes) work? The outer class for inner=20
>>> classes effectively act as a namespace, so it makes sense to me to u=
se=20
>>> syntax that is similar to namespaces.
>>>=20
>>> I'll look into the rest when there is a new implementation, since I=20
>>> assume some details will still be clarified and fixed as part of=20
>>> implementing the proposal.
>>>=20
>>> Best regards
>>> Tim D=C3=BCsterhus
>>>=20
>>=20
>> I am not particularly attached to the separator. I specifically chose=
 it due to being a mixture of :: and -> and -: seemed like a bad idea. I=
n other words, an inner class felt natural to use :> -- however, I have =
some issues with it myself. Particularly, it is too much like |> and as =
shown in the namespace RFC, way too easy to typo. Personally, after usin=
g it for a few days, I'd almost rather go back to :: ...
>>=20
>> I will give \\ a try, but it has to be typed quite a bit when referen=
cing inner classes, so keeping it easy to type is a must. I feel like \\=
 requires a large movement to type, at least on a qwerty non-english key=
board. Maybe people using other keyboards can chime in.
> Please go back to ::. The double colon was perfectly fine, the only th=
ing which was weird was the implicit constant. It's fine for constants a=
nd inner classes to share the same name scoping (i.e. a constant must no=
t share a name with an inner class). But an inner class should not be an=
 actual constant.
>=20
> But otherwise, this was perfectly fine.
>=20

My biggest issue with `::` is that it gets weird:

class Foo {
  public class Bar {}
  public const Bar =3D "";
  public static function Bar() {}
}

echo Foo::Bar; // this is the constant
new Foo::Bar(); // this is the class
Foo::Bar(); // this is the method
new (Foo::Bar()); // this is the method
new (Foo::Bar); // this is constant

I can now differentiate between these all in the AST, but it seems weird=
 to me. If we go this route, I'd personally have the preference to allow=
 them all and let people's code-style dictate what is acceptable or not =
-- assuming I can ensure there is no ambiguity in the grammar. At least =
with `:>` (or something else) we don't have to even have that discussion=
. :)

>>> I don't think that inner classes are sufficiently valuable
>>=20
>> I'm curious why some people feel this way and why some other people a=
re saying the opposite (emphatically). I'll nudge the private emails I'v=
e received to speak up publicly on the list as well. But, why do you fee=
l this way?
>=20
> I don't know why some people feel this way, but at least with the auto=
loading mechanisms we have in PHP there are definite limitations to mult=
iple classes in one file:
> - If you deserialize your data structure and it contains another class=
, whose name does not match the file name, you better hope to god that i=
t has been autoloaded already. Surprising failures in production follow.=
 (e.g.: the amphp\parallel process runner will try to serialize your exc=
eption. That's fine. But as soon as it's accidentally bubbling up and as=
 it's not autoloadable, the hell breaks loose.)
> - Enums or Data Transfer objects specific to one or multiple functions=
 of only this specific class would naturally fit into the same file. But=
 you can't do it ... because the autoloading might try to load the enum =
first, before the class whose constructor or function you want to call i=
s actually loaded.
> - Now, if you actually stuff multiple classes / enums into a single fi=
le, it's non-trivial to figure out (as the human reader, but obviously f=
or the autoloader too) which file to access to read up the definition of=
 a specific enum (short of using dedicated tooling for it).
>=20
>=20
> Certainly, one may say - yeah, just religiously use different files fo=
r ... every ... single ... class.
> But what's the point of that dogma?
> It definitely doesn't help the organization of dedicated helper struct=
ures tied to a single class.
> It's a tool for organization. It's not complex to understand.
>=20
> Outside of very puristic arguments I don't see any reason why one woul=
d not want inner classes.
>=20
>=20
> Further, with short classes, should they hopefully be introduced as we=
ll, it will become trivial to write shapes for any internal datastructur=
es - simply using a "class Point(int $x, int $y); private Point $pos;" r=
ather than "/** @var list{int, int} */ private array $pos;".
> This will be a very ergonomic way to reduce ad-hoc arrays which are on=
ly typehinted by phpdoc, giving proper typing and also safe access to st=
ructures via named accessors rather than [0] and [1] etc.
>=20
> Further Questions on the (original) RFC:
>=20
> - Why is there a conflict in static properties and the inner class nam=
e? The former always has a leading $ sigil.
>=20

Funny enough, this was due to me messing up the AST such that it was try=
ing to access a property instead of a constant. Once I fixed that, the c=
onflict went away.

> - Any particular reason to disallow abstract inner classes? Feels arbi=
trary.
>=20

This went away as well, once I started cleaning up the grammar. Basicall=
y, I couldn't work out how to allow `::` in `extends`. I eventually figu=
red it out once I implemented `:>`. Replacing `:>` with virtually anythi=
ng else is quite possible -- including going back to `::` (I think).

> And a note: I consider the inheritance example misguided as "static co=
nstructors" (static methods which invoke new()) would be a better patter=
n here. Could you maybe come up with another example here?
>=20
>=20
>=20
> Bob
>=20

That was a pretty bad example! It illustrated the point but would probab=
ly be a bad practice.=20

=E2=80=94 Rob
--34be739e28bc46b19a36711ca385a78b
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">=0Ap.=
MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><d=
iv><br></div><div>On Thu, Mar 13, 2025, at 23:26, Bob Weinand wrote:<br>=
</div><blockquote type=3D"cite" id=3D"qt" style=3D""><p>Hey Rob,<br></p>=
<div class=3D"qt-moz-cite-prefix">On 13.3.2025 21:46:49, Rob Landers=0A =
     wrote:<br></div><blockquote type=3D"cite" cite=3D"mid:b10ba5b6-8427=
-4efd-b183-7902b349673f@app.fastmail.com"><div>On Thu, Mar 13, 2025, at =
12:01, Tim D=C3=BCsterhus wrote:<br></div><blockquote type=3D"cite" id=3D=
"qt-qt" style=3D""><div>Hi<br></div><div><br></div><div>Am 2025-03-12 11=
:10, schrieb Rob Landers:<br></div><div>&gt; - Accessing inner classes i=
s done via a new token:=0A          ":&gt;" instead of&nbsp;<br></div><d=
iv>&gt; "::".<br></div><div><br></div><div>I don't particularly like tha=
t. It is =E2=80=9Cinvented syntax=E2=80=9D and=0A          I don't&nbsp;=
<br></div><div>think that inner classes are sufficiently valuable to=0A =
         dedicate an entire&nbsp;<br></div><div>operator to them that co=
uld serve a more useful purpose in=0A          the future.&nbsp;<br></di=
v><div>It also got 4 negative points in the rating back when the=0A     =
     namespace&nbsp;<br></div><div>separator was decided:&nbsp;<a href=3D=
"https://wiki.php.net/rfc/namespaceseparator" class=3D"qt-moz-txt-link-f=
reetext">https://wiki.php.net/rfc/namespaceseparator</a><br></div><div><=
br></div><div>Would `\\` (i.e. two backslashes) work? The outer class for=
=0A          inner&nbsp;<br></div><div>classes effectively act as a name=
space, so it makes sense=0A          to me to use&nbsp;<br></div><div>sy=
ntax that is similar to namespaces.<br></div><div><br></div><div>I'll lo=
ok into the rest when there is a new implementation,=0A          since I=
&nbsp;<br></div><div>assume some details will still be clarified and fix=
ed as=0A          part of&nbsp;<br></div><div>implementing the proposal.=
<br></div><div><br></div><div>Best regards<br></div><div>Tim D=C3=BCster=
hus<br></div><div><br></div></blockquote><div><br></div><div>I am not pa=
rticularly attached to the separator. I=0A        specifically chose it =
due to being a mixture of :: and -&gt; and=0A        -: seemed like a ba=
d idea. In other words, an inner class felt=0A        natural to use :&g=
t; -- however, I have some issues with it=0A        myself. Particularly=
, it is too much like |&gt; and as shown in=0A        the namespace RFC,=
 way too easy to typo. Personally, after using=0A        it for a few da=
ys, I'd almost rather go back to :: ...<br></div><div><br></div><div>I w=
ill give \\ a try, but it has to be typed quite a bit when=0A        ref=
erencing inner classes, so keeping it easy to type is a must.=0A        =
I feel like \\ requires a large movement to type, at least on a=0A      =
  qwerty non-english keyboard. Maybe people using other keyboards=0A    =
    can chime in.<br></div></blockquote><p>Please go back to ::. The dou=
ble colon was perfectly fine, the=0A      only thing which was weird was=
 the implicit constant. It's fine=0A      for constants and inner classe=
s to share the same name scoping=0A      (i.e. a constant must not share=
 a name with an inner class). But=0A      an inner class should not be a=
n actual constant.<br></p><p>But otherwise, this was perfectly fine.<br>=
</p></blockquote><div><br></div><div>My biggest issue with `::` is that =
it gets weird:<br></div><div><br></div><div>class Foo {<br></div><div>&n=
bsp; public class Bar {}<br></div><div>&nbsp; public const Bar =3D "";<b=
r></div><div>&nbsp; public static function Bar() {}<br></div><div>}<br><=
/div><div><br></div><div>echo Foo::Bar; // this is the constant<br></div=
><div>new Foo::Bar(); // this is the class<br></div><div>Foo::Bar(); // =
this is the method<br></div><div>new (Foo::Bar()); // this is the method=
<br></div><div>new (Foo::Bar); // this is constant</div><div><br></div><=
div>I can now differentiate between these all in the AST, but it seems w=
eird to me. If we go this route, I'd personally have the preference to a=
llow them all and let people's code-style dictate what is acceptable or =
not -- assuming I can ensure there is no ambiguity in the grammar. At le=
ast with `:&gt;` (or something else) we don't have to even have that dis=
cussion. :)<br></div><div><br></div><blockquote type=3D"cite" id=3D"qt" =
style=3D""><blockquote type=3D"cite" cite=3D"mid:b10ba5b6-8427-4efd-b183=
-7902b349673f@app.fastmail.com"><blockquote type=3D"cite" id=3D"qt-qt" s=
tyle=3D""><div>I don't&nbsp;think that inner classes are sufficiently va=
luable<br></div></blockquote><div><br></div><div>I'm curious why some pe=
ople feel this way and why some other=0A        people are saying the op=
posite (emphatically). I'll nudge the=0A        private emails I've rece=
ived to speak up publicly on the list as=0A        well. But, why do you=
 feel this way?<br></div></blockquote><p></p><div>I don't know why some =
people feel this way, but at least with the=0A      autoloading mechanis=
ms we have in PHP there are definite=0A      limitations to multiple cla=
sses in one file:<br></div><div> - If you deserialize your data structur=
e and it contains another=0A      class, whose name does not match the f=
ile name, you better hope to=0A      god that it has been autoloaded alr=
eady. Surprising failures in=0A      production follow. (e.g.: the amphp=
\parallel process runner will=0A      try to serialize your exception. T=
hat's fine. But as soon as it's=0A      accidentally bubbling up and as =
it's not autoloadable, the hell=0A      breaks loose.)<br></div><div> - =
Enums or Data Transfer objects specific to one or multiple=0A      funct=
ions of only this specific class would naturally fit into the=0A      sa=
me file. But you can't do it ... because the autoloading might=0A      t=
ry to load the enum first, before the class whose constructor or=0A     =
 function you want to call is actually loaded.<br></div><div> - Now, if =
you actually stuff multiple classes / enums into a=0A      single file, =
it's non-trivial to figure out (as the human reader,=0A      but obvious=
ly for the autoloader too) which file to access to read=0A      up the d=
efinition of a specific enum (short of using dedicated=0A      tooling f=
or it).<br></div><p></p><p></p><div>Certainly, one may say - yeah, just =
religiously use different=0A      files for ... every ... single ... cla=
ss.<br></div><div> But what's the point of that dogma?<br></div><div> It=
 definitely doesn't help the organization of dedicated helper=0A      st=
ructures tied to a single class.<br></div><div> It's a tool for organiza=
tion. It's not complex to understand.<br></div><p></p><p>Outside of very=
 puristic arguments I don't see any reason why one=0A      would not wan=
t inner classes.<br></p><p></p><div>Further, with short classes, should =
they hopefully be introduced=0A      as well, it will become trivial to =
write shapes for any internal=0A      datastructures - simply using a "c=
lass Point(int $x, int $y);=0A      private Point $pos;" rather than "/*=
* @var list{int, int} */=0A      private array $pos;".<br></div><div> Th=
is will be a very ergonomic way to reduce ad-hoc arrays which=0A      ar=
e only typehinted by phpdoc, giving proper typing and also safe=0A      =
access to structures via named accessors rather than [0] and [1]=0A     =
 etc.<br></div><p></p><p>Further Questions on the (original) RFC:<br></p=
><p>- Why is there a conflict in static properties and the inner=0A     =
 class name? The former always has a leading $ sigil.<br></p></blockquot=
e><div><br></div><div>Funny enough, this was due to me messing up the AS=
T such that it was trying to access a property instead of a constant. On=
ce I fixed that, the conflict went away.</div><div><br></div><blockquote=
 type=3D"cite" id=3D"qt" style=3D""><p>- Any particular reason to disall=
ow abstract inner classes? Feels=0A      arbitrary.<br></p></blockquote>=
<div><br></div><div>This went away as well, once I started cleaning up t=
he grammar. Basically, I couldn't work out how to allow `::` in `extends=
`. I eventually figured it out once I implemented `:&gt;`. Replacing `:&=
gt;` with virtually anything else is quite possible -- including going b=
ack to `::` (I think).<br></div><div><br></div><blockquote type=3D"cite"=
 id=3D"qt" style=3D""><p>And a note: I consider the inheritance example =
misguided as=0A      "static constructors" (static methods which invoke =
new()) would be=0A      a better pattern here. Could you maybe come up w=
ith another=0A      example here?<br></p><p><br></p><p>Bob<br></p></bloc=
kquote><div><br></div><div>That was a pretty bad example! It illustrated=
 the point but would probably be a bad practice.&nbsp;</div><div><br></d=
iv><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body></html>
--34be739e28bc46b19a36711ca385a78b--