Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126730
Precedence: bulk
MIME-Version: 1.0
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com>
 <2935d0e2-ddc4-447c-ab37-c9b7337b8b60@app.fastmail.com> <0d94bf183543ee9948fcd31337198438@bastelstu.be>
In-Reply-To: <0d94bf183543ee9948fcd31337198438@bastelstu.be>
Date: Thu, 13 Mar 2025 12:41:50 +0100
Message-ID: <CAPyj-LCWcVTwJGn9fViq+gZnEhbSZ_QKGTRUCmznWb25AR0XWQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: RFC: short and inner classes
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Rob

On Thu, Mar 13, 2025 at 12:01=E2=80=AFPM Tim D=C3=BCsterhus <tim@bastelstu.=
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 a=
nd I don't
> think that inner classes are sufficiently valuable to dedicate an entire
> operator to them

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:

> Currently, many libraries implement =E2=80=9Cinternal=E2=80=9D classes by=
 using a naming convention or an @internal annotation in the docblock. Inne=
r classes enable libraries to define an internal class that cannot be used =
outside the class it is defined inside. This feature is not meant to be use=
d as a =E2=80=9Cmodule=E2=80=9D system, but rather as a way to encapsulate =
logic internal to a class, such as DTOs or helper classes.

At least if I understand this statement correctly.

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.

Ilija