Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126861
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 20 Mar 2025 15:50:38 +0100
To: "Bob Weinand" <bobwei9@hotmail.com>
Cc: internals@lists.php.net
Message-ID: <8a16b81c-7dab-4523-a352-76ba0cb4e771@app.fastmail.com>
In-Reply-To: 
 <AM8P250MB0170601416CA1D75F128D80FE2D92@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com>
 <CAO__Xv4END_NsATOGSnCArGuP_UmSpMxSMsSNPsQZnLooOWTsQ@mail.gmail.com>
 <3e4ba7ea-a154-452d-abfc-05ef1322fade@app.fastmail.com>
 <AM8P250MB0170DE2A7E1AEE1FE1ED1F7CE2DF2@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <782d76d9-711a-4cee-ae0e-fe0d69973f53@app.fastmail.com>
 <DU2P250MB0176FD3F525DFCA32D5A55D6E2DE2@DU2P250MB0176.EURP250.PROD.OUTLOOK.COM>
 <48dce917-d147-456b-9f03-c7e23411adff@app.fastmail.com>
 <AM8P250MB0170601416CA1D75F128D80FE2D92@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Subject: Re: [PHP-DEV] RFC: short and inner classes
Content-Type: multipart/alternative;
 boundary=ed1cec6c477d4c7cb0dbc849acecc010
From: rob@bottled.codes ("Rob Landers")

--ed1cec6c477d4c7cb0dbc849acecc010
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Wed, Mar 19, 2025, at 21:09, Bob Weinand wrote:
>=20
>=20
> On 19.3.2025 16:04:06, Rob Landers wrote:
>> On Tue, Mar 18, 2025, at 03:37, Bob Weinand wrote:
>>> Okay, I see the point with LSP. I'm not sure whether we need to pres=
erve LSP for that specific scenario, but neither can I say that we shoul=
d ignore it.
>>>=20
>>> (Effectively implementing LSP would mean that there's an implicit in=
terface matching all public method signatures of the parent class, for c=
hild classes - which is doable, but possibly too much for the initial RF=
C.)
>>>=20
>>> I would however ask, should we not implement LSP compatible inner cl=
asses, to enforce that no child class may name a class the same than any=
 non-private inner class declared by any of its parents, until we resolv=
e this question (in possibly a future version of PHP).
>>> I do not think we should bar ourselves from allowing this in the fut=
ure.
>>=20
>> I'm not sure I understand what you are asking. But I think you are sa=
ying the following should be illegal?
>>=20
>> class ParentOuter {
>>   class ParentInner {}
>> }
>>=20
>> class ChildOuter extends ParentOuter {
>>   class ParentInner {} // not allowed
>> }
> Precisely.
>=20
>>> And not pretending starts with using a different symbol than a backs=
lash.
>>=20
>> I have been thinking about this for a couple of days now... When thin=
king through the ramifications of my decision to use :> over ::, this wi=
ll also affect generics, most likely -- whenever that happens. This is b=
ecause if this RFC passes, generics will want to be consistent with what=
ever exists currently.
>>=20
>> If we were to use :>, then generics would probably look something lik=
e this to be consistent:
>>=20
>> class Box<T> {
>>   public function add(self:>T $item) {}
>> }
>>=20
>> The same thing would also probably apply to ::
>>=20
>> class Box<T> {
>>   public function add(self::T $item) {}
>> }
>>=20
>> With `\`, it nearly follows exactly what you would expect-ish:
>>=20
>> use \Box\T as T;
>>=20
>> class Box<T> {
>>   public function add(T $item) {}
>>=20
>> // or without use
>>   public function add(Box\T $item) {}
>> }
>>=20
>> With `\`, we can also just automatically check the current class as p=
art of namespace resolution when compiling:
>>=20
>> class Box<T> {
>>   public function add(T $item) {}
>> }
>>=20
>> This would also make it easier to user inner classes:
>>=20
>> class Outer {
>>   public class Inner {}
>>   public function foo(Inner $bar) {}
>> }
>>=20
>> The other syntax options do not allow this; at least, I don't think s=
o. I'm very heavily leaning towards `\` as the separator.
>>=20
>> =E2=80=94 Rob
> I'm failing to understand why you'd think this would be related at all?
>=20
> If we get generics,
>=20
> class Box<T> {
>   public function add(T $item) {}
> }
>=20
> would just work, without any use or such. There will not be a symbol B=
ox::T or Box\T, just all mentions of T within the Box class will be take=
n as "this is the generic placeholder" and the compiler takes care.
> It's not like that T will be directly accessible from outside of the c=
lass or actually a proper type, unlike inner classes.
>=20
> A generic is not an inner class nor will it look like it. Also, there'=
s no accessing of a parents generic - you write class Child<T> extends P=
arentClass<T> - or something along these lines, getting the T available =
for your class.
>=20
> Bob

Yes, that is the question right? It might not affect anything there, but=
 there would probably be an argument to keep it consistent with inner cl=
asses. In PHP, a class is a type; thus an inner class is an inner type, =
and generic types are also an inner type that only exist in the scope of=
 their enclosing class, just like private inner classes.

If my logic is incorrect, let me know.

=E2=80=94 Rob
--ed1cec6c477d4c7cb0dbc849acecc010
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 Wed, Mar 19, 2025, at 21:09, Bob Weinand wrote:<br>=
</div><blockquote type=3D"cite" id=3D"qt" style=3D""><p><br></p><div cla=
ss=3D"qt-moz-cite-prefix">On 19.3.2025 16:04:06, Rob Landers=0A      wro=
te:<br></div><blockquote type=3D"cite" cite=3D"mid:48dce917-d147-456b-9f=
03-c7e23411adff@app.fastmail.com"><div>On Tue, Mar 18, 2025, at 03:37, B=
ob Weinand wrote:<br></div><blockquote type=3D"cite" id=3D"qt-qt" style=3D=
""><p>Okay, I see the point with LSP. I'm not sure whether we need=0A   =
       to preserve LSP for that specific scenario, but neither can I=0A =
         say that we should ignore it.<br></p><p>(Effectively implementi=
ng LSP would mean that there's an=0A          implicit interface matchin=
g all public method signatures of=0A          the parent class, for chil=
d classes - which is doable, but=0A          possibly too much for the i=
nitial RFC.)<br></p><div>I would however ask, should we not implement LS=
P compatible=0A          inner classes, to enforce that no child class m=
ay name a class=0A          the same than any non-private inner class de=
clared by any of=0A          its parents, until we resolve this question=
 (in possibly a=0A          future version of PHP).<br></div><div>I do n=
ot think we should bar ourselves from allowing this=0A          in the f=
uture.<br></div></blockquote><div><br></div><div>I'm not sure I understa=
nd what you are asking. But I think=0A        you are saying the followi=
ng should be illegal?<br></div><div><br></div><div>class ParentOuter {<b=
r></div><div>&nbsp; class ParentInner {}<br></div><div>}<br></div><div><=
br></div><div>class ChildOuter extends ParentOuter {<br></div><div>&nbsp=
; class ParentInner {} // not allowed<br></div><div>}<br></div></blockqu=
ote><p>Precisely.<br></p><blockquote type=3D"cite" cite=3D"mid:48dce917-=
d147-456b-9f03-c7e23411adff@app.fastmail.com"><blockquote type=3D"cite" =
id=3D"qt-qt" style=3D""><div>And not pretending starts with using a diff=
erent symbol=0A          than a backslash.<br></div></blockquote><div><b=
r></div><div>I have been thinking about this for a couple of days now...=
=0A        When thinking through the ramifications of my decision to use=
=0A        :&gt; over ::, this will also affect generics, most likely --=
=0A        whenever that happens. This is because if this RFC passes,=0A=
        generics will want to be consistent with whatever exists=0A     =
   currently.<br></div><div><br></div><div>If we were to use :&gt;, then=
 generics would probably look=0A        something like this to be consis=
tent:<br></div><div><br></div><div>class Box&lt;T&gt; {<br></div><div>&n=
bsp; public function add(self:&gt;T $item) {}<br></div><div>}<br></div><=
div><br></div><div>The same thing would also probably apply to ::<br></d=
iv><div><br></div><div>class Box&lt;T&gt; {<br></div><div>&nbsp; public =
function add(self::T $item) {}<br></div><div>}<br></div><div><br></div><=
div>With `\`, it nearly follows exactly what you would=0A        expect-=
ish:<br></div><div><br></div><div>use \Box\T as T;<br></div><div><br></d=
iv><div>class Box&lt;T&gt; {<br></div><div>&nbsp; public function add(T =
$item) {}<br></div><div><br></div><div>// or without use<br></div><div>&=
nbsp; public function add(Box\T $item) {}<br></div><div>}<br></div><div>=
<br></div><div>With `\`, we can also just automatically check the current=
=0A        class as part of namespace resolution when compiling:<br></di=
v><div><br></div><div>class Box&lt;T&gt; {<br></div><div>&nbsp; public f=
unction add(T $item) {}<br></div><div>}<br></div><div><br></div><div>Thi=
s would also make it easier to user inner classes:<br></div><div><br></d=
iv><div>class Outer {<br></div><div>&nbsp; public class Inner {}<br></di=
v><div>&nbsp; public function foo(Inner $bar) {}<br></div><div>}<br></di=
v><div><br></div><div>The other syntax options do not allow this; at lea=
st, I don't=0A        think so. I'm very heavily leaning towards `\` as =
the separator.<br></div><div><br></div><div id=3D"qt-sig121229152">=E2=80=
=94 Rob<br></div></blockquote><p>I'm failing to understand why you'd thi=
nk this would be related=0A      at all?<br></p><p>If we get generics,<b=
r></p><div>class Box&lt;T&gt; {<br></div><div>&nbsp; public function add=
(T $item) {}<br></div><div>}<br></div><div><br></div><div>would just wor=
k, without any use or such. There will not be a=0A      symbol Box::T or=
 Box\T, just all mentions of T within the Box=0A      class will be take=
n as "this is the generic placeholder" and the=0A      compiler takes ca=
re.<br></div><div>It's not like that T will be directly accessible from =
outside=0A      of the class or actually a proper type, unlike inner cla=
sses.<br></div><div><br></div><div>A generic is not an inner class nor w=
ill it look like it. Also,=0A      there's no accessing of a parents gen=
eric - you write class=0A      Child&lt;T&gt; extends ParentClass&lt;T&g=
t; - or something along=0A      these lines, getting the T available for=
 your class.<br></div><div><br></div><div>Bob<br></div></blockquote><div=
><br></div><div>Yes, that is the question right? It might not affect any=
thing there, but there would probably be an argument to keep it consiste=
nt with inner classes. In PHP, a class is a type; thus an inner class is=
 an inner type, and generic types are also an inner type that only exist=
 in the scope of their enclosing class, just like private inner classes.=
<br></div><div><br></div><div>If my logic is incorrect, let me know.</di=
v><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body>=
</html>
--ed1cec6c477d4c7cb0dbc849acecc010--