Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126957
Feedback-ID: id5114917:Fastmail
Date: Wed, 26 Mar 2025 14:15:38 +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: <45ec0bd6-4c65-4059-8cd1-e195f91b5b13@app.fastmail.com>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com> <AM8P250MB0170601416CA1D75F128D80FE2D92@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM> <8a16b81c-7dab-4523-a352-76ba0cb4e771@app.fastmail.com> <AM8P250MB0170CA8F8094797B55ADE424E2D82@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM> <9c4ac301-dfb2-49da-90e5-37a2824fc4e3@app.fastmail.com> <AM8P250MB0170330066F90E056EBA76F8E2D82@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM> <5b1e6d70-a1c9-455c-93d3-6b22cf1fef11@app.fastmail.com> <CAF-mU4zuja0XfemEyC8sJs=+in6Q6F3An7fzWB9+1o31o=Y-8w@mail.gmail.com> <efcac45a-60ac-4145-b012-72d5fef0090c@app.fastmail.com> <52d84a5b-09d3-4e42-9620-a62fb239c21e@app.fastmail.com> <09a82882-f1ee-4bdb-8a27-e46144a711f1@app.fastmail.com> <f4ecdf20-b3e4-4316-8a90-4ecc57abd84a@app.fastmail.com> <B3AFADFC-4714-486B-A824-4F3F3B55F45C@rwec.co.uk> <f8a2377f-aeaf-4092-a967-4049de47ede7@app.fastmail.com> <2512DF25-6B2F-4C18-8F49-17F2665ADB53@rwec.co.uk> <45ec0bd6-4c65-4059-8cd1-e195f91b5b13@app.fastmail.com>
Message-ID: <2162332A-0022-4E8F-AC9D-4DD931D165D9@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 26 March 2025 00:22:47 GMT, Rob Landers <rob@bottled=2Ecodes> wrote:
>
>To be clear, I'm not trying to be difficult=2E As you mentioned, these we=
re all things I had to think about for nested classes too=2E I know how nes=
ted classes work and why=2E How file-private would work, on the other hand,=
 I have put little thought into=2E You say it is obvious (to paraphrase), b=
ut the devil is in the details, and there isn't much prior-art to draw from=
 here either=2E


I think in some ways this is similar to the discussion I had with Edmond o=
n the async thread - my starting assumption is that new features should be =
consistent with existing ones, unless there's a good reason to make an exce=
ption=2E=20

For instance, the language has various built-in types, so if we add a new =
type, I would assume it will work in all the places that other types work=
=2E It might be useful to ask questions like "does it need any special hand=
ling as a return type?" but the answer will nearly always be "no"=2E Asking=
 "what behaviour should it have as a return type?" is only necessary if you=
've answered "yes" to the simpler question=2E

Similarly, the language has three built-in access levels, so if we add a n=
ew one, I would assume it will work in all the same places, unless there's =
some specific reason to add a special case=2E


>I agree, but these are all things we'd have to consider=2E I, personally,=
 would consider it working the other way around=2E A trait declaring filepr=
ivate would only be accessible in the trait; otherwise you would have to ex=
plain how fileprivate works without saying "the file it is written in" and =
in a way that is easy to understand -- for the RFC + docs=2E I don't know i=
f it would be useless or useful though=2E


Just to be clear, my description is just how traits work today=2E The phra=
se "compiler-assisted copy-and-paste" is widely used; I thought it was in t=
he manual, but can't see it at a glance=2E As soon as you talk about "inher=
iting from traits", you're going to be on the wrong track=2E


Following the reasoning above, my thought process goes like this:=20

1) What does "private" mean in a trait?

It means "copy this property / method with a private modifier by default"=
=2E  Access is granted to all code in the target class, not just other code=
 in the trait=2E

2) Can that apply to the proposed description of "fileprivate"/"samefile"?

Yes=2E

3) Is there a good reason to change that meaning and make the new feature =
inconsistent?

I don't think so=2E

Any change would mean changing the description of traits (they would no lo=
nger just be copied and pasted code), and would lead to additional question=
s (e=2Eg=2E what happens when the target class changes the visibility with =
an "as" clause?)=2E

Any inconsistent behaviour should have to clear a high bar=2E


Rowan Tommins
[IMSoP]