Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126812
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 17 Mar 2025 19:58:39 +0100
To: "Bob Weinand" <bobwei9@hotmail.com>, "fennic log" <fenniclog@gmail.com>
Cc: internals@lists.php.net
Message-ID: <782d76d9-711a-4cee-ae0e-fe0d69973f53@app.fastmail.com>
In-Reply-To: 
 <AM8P250MB0170DE2A7E1AEE1FE1ED1F7CE2DF2@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>
Subject: Re: [PHP-DEV] RFC: short and inner classes
Content-Type: multipart/alternative;
 boundary=301cea8b1ff646038d13b9a68efc01d5
From: rob@bottled.codes ("Rob Landers")

--301cea8b1ff646038d13b9a68efc01d5
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Mon, Mar 17, 2025, at 19:05, Bob Weinand wrote:
> Hey Rob,
>=20
> On 17.3.2025 17:53:26, Rob Landers wrote:
>> On Mon, Mar 17, 2025, at 16:30, fennic log wrote:
>>> 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 `->` if the class is initialized?
>>=20
>> There's quite a long thread already about this very topic. That being=
 said, the inner class has no bearing on whether the outer class is inst=
antiated or not. Originally, I used `::` as the separator, but it seems =
there are some good arguments for `\`, so we will see.
> I have not grasped any single argument in favour of \, except "other l=
anguages are doing it too", "existing tooling splitting on backslash wou=
ld continue to work" and "we could use the existing use statement as is".
>=20
>=20
> The problems are numerous though:
> 1. Unlike other languages (e.g. C# and java), namespaces and classes m=
ay share a name in PHP. E.g. class "Y" in a namespace "X" and class "X" =
may not exist both. In PHP that's allowed. Inner classes compete with na=
mespaced classes for their fully qualified name.
> 2. Autoloading will have to become aware of inner classes.
> 3. Autoloading will have to do a non-cacheable check for existence on =
the inner class, before iteratively testing whether any parent has a res=
pective .php file. Currently autoloading takes a class name, transforms =
it to a single canonical path, and includes it. Always succeeding.
> 4. Humans, navigating to a path, will not be able to navigate to a fil=
e directly but have to search for it.
> 5. Tooling splitting on backslash might assume the 1:1 mapping to the =
filesystem and break. It's really not a catch all. Some things may be br=
oken and some not, but all need to be probably revisited anyway.
> 6. It makes accessing via parent, self or static weird. These keywords=
 have always been followed by a double colon. (Even if this particular R=
FC does not end up adding them) And it will conflict with a namespace na=
med "parent" for example.
> 7. At least right now, every backslash identified symbol is trivially =
universally public. With \ as an inner class separator, this would no lo=
nger be the case. Maybe that will eventually change, but today this can =
be relied upon.
>=20
> Also, just because other languages are doing a mistake, it does not me=
an we have to repeat it. They are generally doing it because their ident=
ifier separator is universal and it's consistent. It does not mean that =
it's without its own problems.
>=20
>=20
> Using the double colon is a very minor BC break (accessing a class by =
a class constant value?! That's also quite inconsistent that it works at=
 all, as you can't do that with normal constants, only class constants.).
> Using another sigil would also be possible (like :>). But for the back=
slash I only see drawbacks.
>=20
> Also, nothing precludes us from allowing "use Foo\Bar::Inner;".
>=20
>=20
>=20
>>> 3. The idea that extending the parent class doesnt no inherit the ch=
ild classes doesnt make sense to me.=20
>>> As then if you extend a parent class and call a function of that cla=
ss 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
>>=20
>> I'm not sure what you mean. When you inherit a class, you do not nece=
ssarily 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 o=
f issues with LSP. This is specifically why inheritance works the way it=
 does in this RFC and why `static::` is forbidden.
> I don't understand the problem here.
>=20
>=20
> for each nested class in parent class:
>     class_alias(substitute parent class with child class in class name=
, class name)
>=20
> Very simple. There's no magic needed, it can be simply class aliases. =
This will also make static, self and parent trivially work.
>=20

PHP doesn't go out of its way to prevent the developer from violating LS=
P -- but where it can, it does. If a type were inherited, then the subcl=
asses wouldn't be able to guarantee that an inner/nested class implement=
ed the parent inner/nested class. Or, if it did, it would require that a=
ll subclasses using a class of the same name MUST inherit from the paren=
t class as well.

This is non-trivial to implement as the parent class may or may not have=
 been compiled yet when we are compiling the subclass. So, we have no id=
ea what the parent class actually looks like until runtime. Further, it =
is much simpler to reason about each class as a distinct type vs. maybe =
inheriting a type from a supertype.

Thus, if you want to inherit from the super-class's inner classes, you c=
an, but this RFC won't force you to do so. In my mind, this is the bigge=
st argument for a `\`, because the enclosing class acts more like a name=
space than a type, from the perspective of the inner class.

If we were to embrace `\`, then it could be argued that a namespace is t=
echnically a class in itself, (but a partial class, to borrow from C# te=
rminology) and every class in a namespace is essentially just a public c=
lass in that super-class/namespace.

Nobody has argued that perspective, but I believe it may be interesting =
(and would lay a foundation for namespace private/public class behavior/=
visibility). That being said, it truly does cause issues with autoloadin=
g -- at least, PSR-4 autoloading -- and I'm not sure whether we should s=
olve that problem here; however, it is something to be cognizant of, for=
 sure. There are other types of autoloading supported by tools, such as =
composer, that do not have any issues with using `\` as a separator.

> On 15.3.2025 00:37:08, Rob Landers wrote:
>=20
>=20
>=20
>> Classes don't actually know their inner classes -- they aren't like p=
roperties. In essence, an inner class is just a regular class with a fun=
ny name and access to scopes it wouldn't normally have access to. We cou=
ld probably add `getOuterClass(): string` if that is useful. It is possi=
ble to keep track of a class's inner classes, but then that introduces a=
 paradox chicken/egg type problem during construction, which may or may =
not be a problem.
>>=20
>=20
>=20
> I don't see the chicken-and-egg problem here. You can simply collect a=
ll the inner class names at compilation. You don't even need to actually=
 store the zend_class_entry - just collect the names and fetch from the =
class table at runtime (and ignore missing ones, e.g. if there was an er=
ror during linking).
>=20

=F0=9F=99=83sometimes the obvious solutions are the best solutions.

=E2=80=94 Rob
--301cea8b1ff646038d13b9a68efc01d5
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 Mon, Mar 17, 2025, at 19:05, 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 17.3.2025 17:53:26, Rob Landers=0A =
     wrote:<br></div><blockquote type=3D"cite" cite=3D"mid:3e4ba7ea-a154=
-452d-abfc-05ef1322fade@app.fastmail.com"><div>On Mon, Mar 17, 2025, at =
16:30, fennic log wrote:<br></div><blockquote type=3D"cite" id=3D"qt-qt"=
 style=3D""><div dir=3D"ltr"><div class=3D"qt-qt-gmail_quote qt-qt-gmail=
_quote_container"><div>2. As with any syntax change and new operator the=
re=0A              needs to be very careful consideration, do we need a =
new=0A              operation, or could `::` if the parent is static or=0A=
              `-&gt;` if the class is initialized?<br></div></div></div>=
</blockquote><div><br></div><div>There's quite a long thread already abo=
ut this very topic.=0A        That being said, the inner class has no be=
aring on whether the=0A        outer class is instantiated or not. Origi=
nally, I used `::` as=0A        the separator, but it seems there are so=
me good arguments for=0A        `\`, so we will see.<br></div></blockquo=
te><p>I have not grasped any single argument in favour of \, except=0A  =
    "other languages are doing it too", "existing tooling splitting on=0A=
      backslash would continue to work" and "we could use the existing=0A=
      use statement as is".<br></p><p></p><div>The problems are numerous=
 though:<br></div><div> 1. Unlike other languages (e.g. C# and java), na=
mespaces and=0A      classes may share a name in PHP. E.g. class "Y" in =
a namespace "X"=0A      and class "X" may not exist both. In PHP that's =
allowed. Inner=0A      classes compete with namespaced classes for their=
 fully qualified=0A      name.<br></div><div> 2. Autoloading will have t=
o become aware of inner classes.<br></div><div> 3. Autoloading will have=
 to do a non-cacheable check for existence=0A      on the inner class, b=
efore iteratively testing whether any parent=0A      has a respective .p=
hp file. Currently autoloading takes a class=0A      name, transforms it=
 to a single canonical path, and includes it.=0A      Always succeeding.=
<br></div><div> 4. Humans, navigating to a path, will not be able to nav=
igate to a=0A      file directly but have to search for it.<br></div><di=
v> 5. Tooling splitting on backslash might assume the 1:1 mapping to=0A =
     the filesystem and break. It's really not a catch all. Some things=0A=
      may be broken and some not, but all need to be probably revisited=0A=
      anyway.<br></div><div> 6. It makes accessing via parent, self or s=
tatic weird. These=0A      keywords have always been followed by a doubl=
e colon. (Even if=0A      this particular RFC does not end up adding the=
m) And it will=0A      conflict with a namespace named "parent" for exam=
ple.<br></div><div> 7. At least right now, every backslash identified sy=
mbol is=0A      trivially universally public. With \ as an inner class s=
eparator,=0A      this would no longer be the case. Maybe that will even=
tually=0A      change, but today this can be relied upon.<br></div><p></=
p><p>Also, just because other languages are doing a mistake, it does=0A =
     not mean we have to repeat it. They are generally doing it because=0A=
      their identifier separator is universal and it's consistent. It=0A=
      does not mean that it's without its own problems.<br></p><p></p><d=
iv>Using the double colon is a very minor BC break (accessing a=0A      =
class by a class constant value?! That's also quite inconsistent=0A     =
 that it works at all, as you can't do that with normal constants,=0A   =
   only class constants.).<br></div><div> Using another sigil would also=
 be possible (like :&gt;). But for=0A      the backslash I only see draw=
backs.<br></div><p></p><p>Also, nothing precludes us from allowing "use =
Foo\Bar::Inner;".<br></p><p><br></p><blockquote type=3D"cite" cite=3D"mi=
d:3e4ba7ea-a154-452d-abfc-05ef1322fade@app.fastmail.com"><blockquote typ=
e=3D"cite" id=3D"qt-qt" style=3D""><div dir=3D"ltr"><div class=3D"qt-qt-=
gmail_quote qt-qt-gmail_quote_container"><div>3. The idea that extending=
 the parent class doesnt no=0A              inherit the child classes do=
esnt&nbsp;make sense to me.&nbsp;<br></div><div>As then if you extend a =
parent class and call a=0A              function of that class which cou=
ld rely on the existence=0A              of an inner class, I can see a =
lot of headaches caused by=0A              this exact scenario.<br></div=
><div>As a developer, if I extend a class, I expect the=0A              =
entire dependance of that class to be inherited, otherwise=0A           =
   the extending class won't work.&nbsp;<br></div></div></div></blockquo=
te><div><br></div><div>I'm not sure what you mean. When you inherit a cl=
ass, you do=0A        not necessarily inherit everything from its superc=
lass. You are=0A        free to override it however you want. Since we a=
re defining=0A        "types" in the sense of PHP, we cannot merely inhe=
rit a "type",=0A        otherwise we would cause all kinds of issues wit=
h LSP. This is=0A        specifically why inheritance works the way it d=
oes in this RFC=0A        and why `static::` is forbidden.<br></div></bl=
ockquote><p>I don't understand the problem here.<br></p><p></p><div>for =
each nested class in parent class:<br></div><div> &nbsp;&nbsp;&nbsp; cla=
ss_alias(substitute parent class with child class in class=0A      name,=
 class name)<br></div><p></p><p>Very simple. There's no magic needed, it=
 can be simply class=0A      aliases. This will also make static, self a=
nd parent trivially=0A      work.<br></p></blockquote><div><br></div><di=
v>PHP doesn't go out of its way to prevent the developer from violating =
LSP -- but where it can, it does. If a type were inherited, then the sub=
classes wouldn't be able to guarantee that an inner/nested class impleme=
nted the parent inner/nested class. Or, if it did, it would require that=
 all subclasses using a class of the same name MUST inherit from the par=
ent class as well.<br></div><div><br></div><div>This is non-trivial to i=
mplement as the parent class may or may not have been compiled yet when =
we are compiling the subclass. So, we have no idea what the parent class=
 actually looks like until runtime. Further, it is much simpler to reaso=
n about each class as a distinct type vs. maybe inheriting a type from a=
 supertype.<br></div><div><br></div><div>Thus, if you want to inherit fr=
om the super-class's inner classes, you can, but this RFC won't force yo=
u to do so. In my mind, this is the biggest argument for a `\`, because =
the enclosing class acts more like a namespace than a type, from the per=
spective of the inner class.<br></div><div><br></div><div>If we were to =
embrace `\`, then it could be argued that a namespace is technically a c=
lass in itself, (but a partial class, to borrow from C# terminology) and=
 every class in a namespace is essentially just a public class in that s=
uper-class/namespace.<br></div><div><br></div><div>Nobody has argued tha=
t perspective, but I believe it may be interesting (and would lay a foun=
dation for namespace private/public class behavior/visibility). That bei=
ng said, it truly does cause issues with autoloading -- at least, PSR-4 =
autoloading -- and I'm not sure whether we should solve that problem her=
e; however, it is something to be cognizant of, for sure. There are othe=
r types of autoloading supported by tools, such as composer, that do not=
 have any issues with using `\` as a separator.</div><div><br></div><blo=
ckquote type=3D"cite" id=3D"qt" style=3D""><p>On 15.3.2025 00:37:08, Rob=
 Landers wrote:<br></p><p><br></p><blockquote type=3D"cite"><div><p>Clas=
ses don't actually know their inner classes -- they=0A            aren't=
 like properties. In essence, an inner class is just a=0A            reg=
ular class with a funny name and access to scopes it=0A            would=
n't normally have access to. We could probably add=0A            `getOut=
erClass(): string` if that is useful. It is possible=0A            to ke=
ep track of a class's inner classes, but then that=0A            introdu=
ces a paradox chicken/egg type problem during=0A            construction=
, which may or may not be a problem.<br></p></div></blockquote><p><br></=
p><p>I don't see the chicken-and-egg problem here. You can simply=0A    =
  collect all the inner class names at compilation. You don't even=0A   =
   need to actually store the zend_class_entry - just collect the=0A    =
  names and fetch from the class table at runtime (and ignore=0A      mi=
ssing ones, e.g. if there was an error during linking).<br></p></blockqu=
ote><div><br></div><div>=F0=9F=99=83sometimes the obvious solutions are =
the best solutions.</div><div><br></div><div id=3D"sig121229152">=E2=80=94=
 Rob<br></div></body></html>
--301cea8b1ff646038d13b9a68efc01d5--