Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126731
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 13 Mar 2025 13:56:30 +0100
To: internals@lists.php.net
Message-ID: <ebf1997e-c93e-4b2a-b203-7c67860689b0@app.fastmail.com>
In-Reply-To: 
 <CAPyj-LCWcVTwJGn9fViq+gZnEhbSZ_QKGTRUCmznWb25AR0XWQ@mail.gmail.com>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com>
 <2935d0e2-ddc4-447c-ab37-c9b7337b8b60@app.fastmail.com>
 <0d94bf183543ee9948fcd31337198438@bastelstu.be>
 <CAPyj-LCWcVTwJGn9fViq+gZnEhbSZ_QKGTRUCmznWb25AR0XWQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: RFC: short and inner classes
Content-Type: multipart/alternative;
 boundary=bf75109edf8f41da8e14749da403b383
From: rob@bottled.codes ("Rob Landers")

--bf75109edf8f41da8e14749da403b383
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 13, 2025, at 12:41, Ilija Tovilo wrote:
> Hi Rob
>=20
> On Thu, Mar 13, 2025 at 12:01=E2=80=AFPM Tim D=C3=BCsterhus <tim@baste=
lstu.be> wrote:
> >
> > Am 2025-03-12 11:10, schrieb Rob Landers:
> > > - Accessing inner classes is done via a new token: ":>" instead of
> > > "::".
> >
> > I don't particularly like that. It is =E2=80=9Cinvented syntax=E2=80=
=9D and I don't
> > think that inner classes are sufficiently valuable to dedicate an en=
tire
> > operator to them
>=20
> I would like to echo these thoughts. I also think the RFC is kind of
> missing the mark. Arguably the most common use-case for `@internal` is
> to restrict a class to a specific package/module or namespace,
> regardless of the user's class hierarchy. I believe you specifically
> call this a non-goal:
>=20
> > Currently, many libraries implement =E2=80=9Cinternal=E2=80=9D class=
es by using a naming convention or an @internal annotation in the docblo=
ck. Inner classes enable libraries to define an internal class that cann=
ot be used outside the class it is defined inside. This feature is not m=
eant to be used as a =E2=80=9Cmodule=E2=80=9D system, but rather as a wa=
y to encapsulate logic internal to a class, such as DTOs or helper class=
es.
>=20
> At least if I understand this statement correctly.
>=20
> In that case, I see much less value in nested classes. They might
> still be ok if they are extremely simple, but the proposal is
> currently quite complex. It has a custom operator, it deals with
> shadowing, LSP, runtime resolution and more, in addition to visibility
> which is the actual goal. Maybe more use-cases are enabled, but I
> don't think they are currently well described. Assuming visibility can
> partially be implemented in a simpler way (e.g. top-level,
> file-private classes), the costs seem to outweigh the benefits in my
> opinion. Hence I would not be in favor of the RFC in this or a similar
> form.
>=20
> Ilija
>=20

Hey Ilija,

> the proposal is
> currently quite complex.

Most of this is just describing how classes work already and going in-de=
pth on where there may be confusion -- there are no significant changes =
to how classes actually work. The actual changes to the engine are basic=
ally just visibility rules, some syntax changes (to allow nesting `class=
` inside another class), and handling the new operator. The hard part is=
 explaining how classes work, because they don't really have a defined b=
ehavior. In other words, I cannot just say "the way this works doesn't c=
hange anything."

> They might
> still be ok if they are extremely simple

And now you can understand why they WERE just simple classes (short clas=
ses). So, you can see why I originally bundled them together because of =
this EXACT argument. :sigh:

> to restrict a class to a specific package/module or namespace,
> regardless of the user's class hierarchy. I believe you specifically
> call this a non-goal:

I was specifically echoing this callout from Micha=C5=82 earlier in this=
 thread and other emails/comments I have gotten off-list; including my o=
wn libraries. I usually have DTOs that I want to use specifically for ce=
rtain things, but not expose them in the user application -- or even the=
 rest of the library. This isn't a replacement for "modules" or "namespa=
ce privacy" but rather, complements it, if we ever implement it.

=E2=80=94 Rob
--bf75109edf8f41da8e14749da403b383
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>On Thu, Mar 13,=
 2025, at 12:41, Ilija Tovilo wrote:<br></div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>Hi Rob<br></div><div><br></div><div>On Thu, Ma=
r 13, 2025 at 12:01=E2=80=AFPM Tim D=C3=BCsterhus &lt;<a href=3D"mailto:=
tim@bastelstu.be">tim@bastelstu.be</a>&gt; wrote:<br></div><div>&gt;<br>=
</div><div>&gt; Am 2025-03-12 11:10, schrieb Rob Landers:<br></div><div>=
&gt; &gt; - Accessing inner classes is done via a new token: ":&gt;" ins=
tead of<br></div><div>&gt; &gt; "::".<br></div><div>&gt;<br></div><div>&=
gt; I don't particularly like that. It is =E2=80=9Cinvented syntax=E2=80=
=9D and I don't<br></div><div>&gt; think that inner classes are sufficie=
ntly valuable to dedicate an entire<br></div><div>&gt; operator to them<=
br></div><div><br></div><div>I would like to echo these thoughts. I also=
 think the RFC is kind of<br></div><div>missing the mark. Arguably the m=
ost common use-case for `@internal` is<br></div><div>to restrict a class=
 to a specific package/module or namespace,<br></div><div>regardless of =
the user's class hierarchy. I believe you specifically<br></div><div>cal=
l this a non-goal:<br></div><div><br></div><div>&gt; Currently, many lib=
raries implement =E2=80=9Cinternal=E2=80=9D classes by using a naming co=
nvention or an @internal annotation in the docblock. Inner classes enabl=
e libraries to define an internal class that cannot be used outside the =
class it is defined inside. This feature is not meant to be used as a =E2=
=80=9Cmodule=E2=80=9D system, but rather as a way to encapsulate logic i=
nternal to a class, such as DTOs or helper classes.<br></div><div><br></=
div><div>At least if I understand this statement correctly.<br></div><di=
v><br></div><div>In that case, I see much less value in nested classes. =
They might<br></div><div>still be ok if they are extremely simple, but t=
he proposal is<br></div><div>currently quite complex. It has a custom op=
erator, it deals with<br></div><div>shadowing, LSP, runtime resolution a=
nd more, in addition to visibility<br></div><div>which is the actual goa=
l. Maybe more use-cases are enabled, but I<br></div><div>don't think the=
y are currently well described. Assuming visibility can<br></div><div>pa=
rtially be implemented in a simpler way (e.g. top-level,<br></div><div>f=
ile-private classes), the costs seem to outweigh the benefits in my<br><=
/div><div>opinion. Hence I would not be in favor of the RFC in this or a=
 similar<br></div><div>form.<br></div><div><br></div><div>Ilija<br></div=
><div><br></div></blockquote><div><br></div><div>Hey&nbsp;Ilija,<br></di=
v><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>the=
 proposal is<br></div><div>currently quite complex.<br></div></blockquot=
e><div><br></div><div>Most of this is just describing how classes work a=
lready and going in-depth on where there may be confusion -- there are n=
o significant changes to how classes actually work. The actual changes t=
o the engine are basically just visibility rules, some syntax changes (t=
o allow nesting `class` inside another class), and handling the new oper=
ator. The hard part is explaining how classes work, because they don't r=
eally have a defined behavior. In other words, I cannot just say "the wa=
y this works doesn't change anything."<br></div><div><br></div><blockquo=
te type=3D"cite" id=3D"qt" style=3D""><div>They might<br></div><div>stil=
l be ok if they are extremely simple<br></div></blockquote><div><br></di=
v><div>And now you can understand why they WERE just simple classes (sho=
rt classes). So, you can see why I originally bundled them together beca=
use of this EXACT argument. :sigh:<br></div><div><br></div><blockquote t=
ype=3D"cite" id=3D"qt" style=3D""><div>to restrict a class to a specific=
 package/module or namespace,<br></div><div>regardless of the user's cla=
ss hierarchy. I believe you specifically<br></div><div>call this a non-g=
oal:<br></div></blockquote><div><br></div><div>I was specifically echoin=
g this callout from Micha=C5=82 earlier in this thread and other emails/=
comments I have gotten off-list; including my own libraries. I usually h=
ave DTOs that I want to use specifically for certain things, but not exp=
ose them in the user application -- or even the rest of the library. Thi=
s isn't a replacement for "modules" or "namespace privacy" but rather, c=
omplements it, if we ever implement it.<br></div><div><br></div><div id=3D=
"sig121229152">=E2=80=94 Rob<br></div></body></html>
--bf75109edf8f41da8e14749da403b383--