Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126615
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 07 Mar 2025 00:48:06 +0100
To: internals@lists.php.net
Message-ID: <ca915103-a68e-4b3f-af10-083968df3876@app.fastmail.com>
In-Reply-To: 
 <CAPyj-LAz=3yX7mCYOijw2irrubgs2b3Piqy42_jpkek5ctKkWA@mail.gmail.com>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com>
 <CAPyj-LAz=3yX7mCYOijw2irrubgs2b3Piqy42_jpkek5ctKkWA@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC: short and inner classes
Content-Type: multipart/alternative;
 boundary=acc889e72acf4c56805f9c9c2bf82575
From: rob@bottled.codes ("Rob Landers")

--acc889e72acf4c56805f9c9c2bf82575
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Thu, Mar 6, 2025, at 23:20, Ilija Tovilo wrote:
> Hi Rob
>=20
> On Thu, Mar 6, 2025 at 12:14=E2=80=AFAM Rob Landers <rob@bottled.codes=
> wrote:
> >
> > I'd like to introduce my RFC for discussion: https://wiki.php.net/rf=
c/short-and-inner-classes
>=20
> Thank you for your proposal.
>=20
> I'm very much against the idea of introducing yet another slightly
> shorter form to declare a class. In your examples (they have been
> removed in the meantime), it's unclear how the syntax interacts with
> inherited constructors, trait-used constructors, whether repetition of
> readonly parent properties leads to a "Cannot modify readonly
> property" error, etc.
>=20
> The concept of visibility for classes does seem useful to me. Some
> questions that crossed my mind when reading the proposal:
>=20
> > Inner classes may only be nested one level deep, may not be a parent=
 class, and may not be declared abstract
>=20
> These restrictions seem somewhat arbitrary. For example, you may want
> a private class to extend another private class, creating some local
> class hierarchy. I think there's value in relaxing this restriction,
> if technically possible.

They're not 100% arbitrary, but mostly due to technical limitations.

- One level deep: Nesting multiple levels results in ambiguous grammar.
- As a parent class: This also results in ambiguity.
- Abstract: If it cannot be a parent class, it doesn't make sense for it=
 to be abstract.

>=20
> > PHP Fatal error:  Private inner class Box::Point cannot be used in t=
he global scope
>=20
> How is this implemented? I presume using a public nested class as type
> hints should be allowed, but these classes may not be loaded when the
> function is declared. We implement delayed variance checks for
> methods, which do trigger the autoloader, but functions do not (since
> they cannot violate variance rules).

This happens at run time, when the function is called. I believe we can =
guarantee that it will pass/fail with one of the following cases:

- The type check passes and everything is fine
- The type check fails (due to not being the correct type); autoloading =
never happens
- The type check succeeds, but it is private/protected; to have an objec=
t of that type, you'd have to have loaded the outer class.

This is no different than having:

function foo(MadeUpClass $c) {}

and then never calling foo.

>=20
> > Visibility Rules: Private and protected inner classes are only insta=
ntiable within their outer class (or subclasses for protected) and canno=
t be used as type declarations outside their outer class. This encapsula=
tion ensures that the inner class=E2=80=99s implementation details remai=
n within their intended scope.
>=20
> This introduces a weird case where methods with parameter or return
> types referring to private classes may not be redeclared in their
> subclasses, given that the type cannot be specified, even if the
> methods themselves are not private or final. You do mention something
> very similar in your e-mail with the __constructor case, but I really
> fail to see how this provides any benefit.

Yes. This is correct and inline with other languages with inner types. T=
he idea behind it is to encapsulate behavior and hide information. The i=
dea is that external code should not know anything about the internal st=
ructure. This grants control over inheritance, which you pointed out, th=
ough it is better to use final to do that. However, it could be useful i=
f you wanted to create a class meant to be inherited (such as a url pars=
er) but prevent modification to important methods via inheritance.

>=20
> I would also like to echo what has been said about the :: operator,
> which feels out of place. I understand that \ comes with additional
> autoloading challenges, namely requiring a fallback autoloading
> strategy that currently does not conform to PSR-4.

It felt natural to me at the time, but I suspect there may be a better n=
omenclature; we just need to discover it.

>=20
> Disclaimer: I have not looked at the implementation at all yet.
>=20
> Ilija
>=20

=E2=80=94 Rob
--acc889e72acf4c56805f9c9c2bf82575
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 Thu, Mar 6, 2025, at 23:20, Ilija Tovilo wrote:<br></d=
iv><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Hi Rob<br></div><=
div><br></div><div>On Thu, Mar 6, 2025 at 12:14=E2=80=AFAM Rob Landers &=
lt;<a href=3D"mailto:rob@bottled.codes">rob@bottled.codes</a>&gt; wrote:=
<br></div><div>&gt;<br></div><div>&gt; I'd like to introduce my RFC for =
discussion:&nbsp;<a href=3D"https://wiki.php.net/rfc/short-and-inner-cla=
sses">https://wiki.php.net/rfc/short-and-inner-classes</a><br></div><div=
><br></div><div>Thank you for your proposal.<br></div><div><br></div><di=
v>I'm very much against the idea of introducing yet another slightly<br>=
</div><div>shorter form to declare a class. In your examples (they have =
been<br></div><div>removed in the meantime), it's unclear how the syntax=
 interacts with<br></div><div>inherited constructors, trait-used constru=
ctors, whether repetition of<br></div><div>readonly parent properties le=
ads to a "Cannot modify readonly<br></div><div>property" error, etc.<br>=
</div><div><br></div><div>The concept of visibility for classes does see=
m useful to me. Some<br></div><div>questions that crossed my mind when r=
eading the proposal:<br></div><div><br></div><div>&gt; Inner classes may=
 only be nested one level deep, may not be a parent class, and may not b=
e declared abstract<br></div><div><br></div><div>These restrictions seem=
 somewhat arbitrary. For example, you may want<br></div><div>a private c=
lass to extend another private class, creating some local<br></div><div>=
class hierarchy. I think there's value in relaxing this restriction,<br>=
</div><div>if technically possible.<br></div></blockquote><div><br></div=
><div>They're not 100% arbitrary, but mostly due to technical limitation=
s.<br></div><div><br></div><div>- One level deep: Nesting multiple level=
s results in ambiguous grammar.<br></div><div>- As a parent class: This =
also results in ambiguity.<br></div><div>- Abstract: If it cannot be a p=
arent class, it doesn't make sense for it to be abstract.<br></div><div>=
<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></div>=
<div>&gt; PHP Fatal error:&nbsp; Private inner class Box::Point cannot b=
e used in the global scope<br></div><div><br></div><div>How is this impl=
emented? I presume using a public nested class as type<br></div><div>hin=
ts should be allowed, but these classes may not be loaded when the<br></=
div><div>function is declared. We implement delayed variance checks for<=
br></div><div>methods, which do trigger the autoloader, but functions do=
 not (since<br></div><div>they cannot violate variance rules).<br></div>=
</blockquote><div><br></div><div>This happens at run time, when the func=
tion is called. I believe we can guarantee that it will pass/fail with o=
ne of the following cases:<br></div><div><br></div><div>- The type check=
 passes and everything is fine<br></div><div>- The type check fails (due=
 to not being the correct type); autoloading never happens<br></div><div=
>- The type check succeeds, but it is private/protected; to have an obje=
ct of that type, you'd have to have loaded the outer class.<br></div><di=
v><br></div><div>This is no different than having:<br></div><div><br></d=
iv><div>function foo(MadeUpClass $c) {}<br></div><div><br></div><div>and=
 then never calling foo.</div><div><br></div><blockquote type=3D"cite" i=
d=3D"qt" style=3D""><div><br></div><div>&gt; Visibility Rules: Private a=
nd protected inner classes are only instantiable within their outer clas=
s (or subclasses for protected) and cannot be used as type declarations =
outside their outer class. This encapsulation ensures that the inner cla=
ss=E2=80=99s implementation details remain within their intended scope.<=
br></div><div><br></div><div>This introduces a weird case where methods =
with parameter or return<br></div><div>types referring to private classe=
s may not be redeclared in their<br></div><div>subclasses, given that th=
e type cannot be specified, even if the<br></div><div>methods themselves=
 are not private or final. You do mention something<br></div><div>very s=
imilar in your e-mail with the __constructor case, but I really<br></div=
><div>fail to see how this provides any benefit.<br></div></blockquote><=
div><br></div><div>Yes. This is correct and inline with other languages =
with inner types. The idea behind it is to encapsulate behavior and hide=
 information. The idea is that external code should not know anything ab=
out the internal structure. This grants control over inheritance, which =
you pointed out, though it is better to use final to do that. However, i=
t could be useful if you wanted to create a class meant to be inherited =
(such as a url parser) but prevent modification to important methods via=
 inheritance.<br></div><div><br></div><blockquote type=3D"cite" id=3D"qt=
" style=3D""><div><br></div><div>I would also like to echo what has been=
 said about the :: operator,<br></div><div>which feels out of place. I u=
nderstand that \ comes with additional<br></div><div>autoloading challen=
ges, namely requiring a fallback autoloading<br></div><div>strategy that=
 currently does not conform to PSR-4.<br></div></blockquote><div><br></d=
iv><div>It felt natural to me at the time, but I suspect there may be a =
better nomenclature; we just need to discover it.</div><div><br></div><b=
lockquote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div>Disclai=
mer: I have not looked at the implementation at all yet.<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>
--acc889e72acf4c56805f9c9c2bf82575--