Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126779
Feedback-ID: id5114917:Fastmail
Date: Sat, 15 Mar 2025 11:53:13 +0000
To: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: short and inner classes
User-Agent: K-9 Mail for Android
In-Reply-To: <4abd7008-ae33-46fe-8bbd-7c99f7c48158@app.fastmail.com>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com> <AM8P250MB01709D7FC3E4FDF07E8995C2E2D22@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM> <4abd7008-ae33-46fe-8bbd-7c99f7c48158@app.fastmail.com>
Message-ID: <0F1E4400-5E26-4E39-88B9-ABD7ABBAEBC4@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 14 March 2025 23:37:08 GMT, Rob Landers <rob@bottled=2Ecodes> wrote:
>I could get behind `::`, but I feel that it introduces human ambiguity=2E=
 I don't believe it would introduce compiler ambiguity, but as a human, I h=
ave to hope the programmers are using a style that makes it obvious what ar=
e inner classes and what are constants/methods=2E

As far as I can see, all four languages I looked up last night (Java, C#, =
Swift, Kotlin) use the same syntax for accessing a nested type as for acces=
sing a property or method, so we'd be following the crowd to use "::"

That said, I think they all also use that same syntax for namespace (or eq=
uivalent) lookups, so the same argument can be made for "\"=2E (Why PHP sep=
arates those isn't entirely clear to me=2E)

Having some new syntax makes them feel more "exotic" to me=2E The C# and S=
wift docs give the impression that nesting types is "just something that ca=
n happen", rather than a whole new language concept to learn=2E

Java's "inner classes" are something different, and I think we should avoi=
d using that term=2E



> Furthermore, I'm relatively certain this approach can be slightly modifi=
ed to support "namespace private/protected" classes, in general=2E So, that=
 will also possibly be a follow-up RFC and having them mixed up will compli=
cate things=2E In any case, I am not a fan of using the namespace separator=
 here=2E

To me namespace, module, or file visibility seem like much more natural ad=
ditions to the language, and to solve most of the same problems as nesting =
types=2E

I guess a public nested class is a bit like a "friend class"? In that it h=
as special access to its surrounding class, but otherwise might as well jus=
t be sharing a namespace with it=2E But it's also necessarily in the same f=
ile, so marking those members "file private" rather than "private" would al=
so allow that=2E

A private nested class can only be explicitly mentioned within that narrow=
 context, which again feels very much equivalent to "file private"=2E


> $user =3D new User:>Builder("Rob")->withEmail("rob@bottled=2Ecodes")->bu=
ild();
>
> The user builder is intrinsically tied to the User class itself, it isn'=
t just a namespace=2E The user builder shares scope with the user class and=
 is able to be the only way to construct a user (barring reflection)=2E

If we had either file or namespace visibility, exactly the same thing coul=
d be achieved with those, and would look like this:=20

$user =3D new User\Builder("Rob")->withEmail("rob@bottled=2Ecodes")->build=
();

The "User" class would have a "file private" or "namespace private" constr=
uctor, callable from the "User\Builder" class but not elsewhere; the build(=
) method would return the "User" instance=2E



I think I'm coming to the conclusion that we should use backslash: nested =
types can be viewed as a shorthand way of having a class and namespace with=
 the same name, plus applying some visibility rules to that namespace=2E

Rowan Tommins
[IMSoP]