Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126337
Precedence: bulk
MIME-Version: 1.0
References: <cf4db2de-4a95-42b1-b343-e19c6ae4d976@app.fastmail.com> <4bad8c629e2402b94a125e54da972586@bastelstu.be>
In-Reply-To: <4bad8c629e2402b94a125e54da972586@bastelstu.be>
Date: Fri, 7 Feb 2025 17:35:40 +0100
Message-ID: <CAPyj-LB7SuJo7nSqip_esGaWL2SABkkwYHnf+x1mNs5D0-wmjA@mail.gmail.com>
Subject: Re: [PHP-DEV] Short class syntax 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 there

On Fri, Feb 7, 2025 at 4:07=E2=80=AFPM Tim D=C3=BCsterhus <tim@bastelstu.be=
> wrote:
>
> I believe Ilija has some proof-of-concept regarding file-private
> classes, which would sidestep the above problem of disambiguating static
> member access.

Indeed. I shared a draft internally and responses were mixed.

https://wiki.php.net/rfc/private-classes-and-functions
https://github.com/php/php-src/compare/master...iluuu1994:php-src:private-c=
lasses

The RFC proposes to allow declaring classes and functions as private,
which will limit their usage to the current file, or more accurately,
to the current namespace block (i.e. namespace {}, not namespace
across files)

The motivation is to allow declaring small helper classes (e.g. mocks
for tests) in the file where they are used. Of course, this is
currently already possible, but discouraged to preserve the ability to
autoload classes. However, autoloading is not necessary for private
members, so this concern goes away.

Furthermore, private mangles the class/function name so that it
doesn't conflict with other files declaring a class/function with the
same private name. For example, multiple tests can create a private
class DbMock without worrying about conflicts.

To summarize, the main benefits for private is:

* Single-use classes/functions live closer to their point of usage.
* It signals to users that the members are not intended to be used
outside the given file.
* It avoids naming conflicts for cases between private members.

The main pushback was that "private" does not sufficiently indicate
the semantics of this feature. This could simply be solved with a
different keyword. I guess for others, "namespace private" is a more
interesting concept.

One thing I disliked about the implementation is that private members
still pollute the global symbol tables. That said, it's not likely to
matter in practice.

Anyway, I didn't have any immediate plans to pursue this RFC, so feel
free to take over in any way you like.

Ilija