Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126801
Precedence: bulk
MIME-Version: 1.0
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com>
 <AM8P250MB01709D7FC3E4FDF07E8995C2E2D22@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <4abd7008-ae33-46fe-8bbd-7c99f7c48158@app.fastmail.com> <0F1E4400-5E26-4E39-88B9-ABD7ABBAEBC4@rwec.co.uk>
 <8bbb484b-96a3-4a3e-881e-2c47d7f433b9@app.fastmail.com> <7C4630DC-3478-4FDD-88C6-D2B27595F02A@rwec.co.uk>
In-Reply-To: <7C4630DC-3478-4FDD-88C6-D2B27595F02A@rwec.co.uk>
Date: Mon, 17 Mar 2025 12:37:52 +0200
Message-ID: <CAAwdEzDwyMjKutWu2FENE5pm17jGZ0kmrNRDQb-OAxwR-ZdHKQ@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC: short and inner classes
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, Rob Landers <rob@bottled.codes>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000064306a06308762eb"
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--00000000000064306a06308762eb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Ma0r 17, 2025 at 9:56=E2=80=AFAM Rowan Tommins [IMSoP] <imsop.php@r=
wec.co.uk>
wrote:

>
>
> On 17 March 2025 07:11:23 GMT, Rob Landers <rob@bottled.codes> wrote:
>
>
> > Which one it resolves to would depend on how you implement autoloading
>
>
> That's just the same as having the same class defined in two files on dis=
k
> - PHP doesn't know which will be used until an autoloader runs.
>
> From what I understand of the proposal, the calling code won't know
> anything different based on it being "nested" or "namespaced", it will ju=
st
> see a class with a long name with some punctuation in.
>
>
The problem for me is not autoloading, but that you can't have the two
classes defined at the same time, while using some other punctuation it
would allow it.
I believe that there are other operators that we can use, to allow this.


> I rather think the other way round: in the short term, a new separator
> would save users a bit of pain with autoloading, but in the long run it
> will look like a weird anomaly that no other language needs.
>
>
There was much discussion about various ways to solve the problem stated in
the RFC, but I think we need to look at it as a broader picture again.
I'll share what I've been thinking about in the past week and didn't yet
had time to reply here.

Right now, PHP only has public classes.
For better encapsulation and cohesion, we want to define some new ways to
define classes with some limited restrictions or improved access.
Taking examples from other languages, we can have two ways to do this:
- namespace private classes, or file-private classes - this controls the
visibility of the class at the namespace or file level. They=E2=80=99re ess=
entially
about managing the scope of classes without changing their fundamental
behavior.
- nested (inner) classes - this allows a class defined inside another to
access private members of its enclosing class, increasing cohesion. And we
can have further here just public visibility, or protected/private
visibility, for better encapsulation.

Given this, I think we could even implement all of these in separate RFCs:
- public nested classes
- file-private classes
- namespace private classes
- protected/private nested classes
- other-grouping-level-that-will-exist-in-the-future private classes

Of all of this, the first, public nested classes are the most simple and
would drive cohesion. And maybe we can have only that for now.
The other features would be mostly important for encapsulation, with
limiting the class visibility.

We just need to agree on a separator/operator, and IMHO, it should be clear
and distinct from namespace separator, as nested classes are a separate
concept.
Maybe having a vote on the operator would be enough.

(As a note, and this might have been discussed already, but I would prefer
to use the term nested class instead of inner class, as in java the inner
classes means non-static classes, and I don't think we should go that way.)

--=20
Alex

--00000000000064306a06308762eb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote gmail=
_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Ma0r 17, 20=
25 at 9:56=E2=80=AFAM Rowan Tommins [IMSoP] &lt;<a href=3D"mailto:imsop.php=
@rwec.co.uk">imsop.php@rwec.co.uk</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><br>
<br>
On 17 March 2025 07:11:23 GMT, Rob Landers &lt;rob@bottled.codes&gt; wrote:=
<br><br>
<br>
&gt; Which one it resolves to would depend on how you implement autoloading=
<br>
<br>
<br>
That&#39;s just the same as having the same class defined in two files on d=
isk - PHP doesn&#39;t know which will be used until an autoloader runs.<br>
<br>
From what I understand of the proposal, the calling code won&#39;t know any=
thing different based on it being &quot;nested&quot; or &quot;namespaced&qu=
ot;, it will just see a class with a long name with some punctuation in.<br=
><br></blockquote><div><br></div><div>The problem for me is not autoloading=
, but that you can&#39;t have the two classes defined at the same time, whi=
le using some other punctuation it would allow it.</div><div>I believe that=
 there are other operators that we can use, to allow this.</div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I rather think the other way round: in the short term, a new separator woul=
d save users a bit of pain with autoloading, but in the long run it will lo=
ok like a weird anomaly that no other language needs.<br>
<br>
</blockquote><div><br></div><div>There was much discussion about various wa=
ys to solve the=C2=A0problem stated in the RFC, but I think we need to look=
 at it as a broader picture again.</div><div>I&#39;ll share what I&#39;ve b=
een thinking about in the past week and didn&#39;t yet had time to reply he=
re.</div><div><br></div><div>Right now, PHP only has public classes.</div><=
div>For better encapsulation and cohesion, we want to define some new ways =
to define classes with some limited restrictions or improved access.</div><=
div>Taking examples from other languages, we can have two ways to do this:<=
/div><div>- namespace private classes, or file-private classes - this contr=
ols the visibility of the class at the namespace or file level.=C2=A0They=
=E2=80=99re essentially about managing the scope of classes without changin=
g their fundamental behavior.</div><div>- nested (inner) classes - this all=
ows a class defined inside another to access private members of its enclosi=
ng class,=C2=A0increasing cohesion. And we can have further here just publi=
c visibility, or protected/private visibility, for better encapsulation.</d=
iv><div><br></div><div>Given this, I think we could even implement all of t=
hese in separate RFCs:</div><div>- public nested classes</div><div>- file-p=
rivate classes</div><div>- namespace private classes</div><div>- protected/=
private nested classes</div><div>- other-grouping-level-that-will-exist-in-=
the-future private classes</div><div><br></div><div>Of all of this, the fir=
st, public nested classes are the most simple and would drive cohesion. And=
 maybe we can have only that for now.</div><div>The other features would be=
 mostly important for encapsulation, with limiting the class visibility.</d=
iv><div><br></div><div>We just need to agree on a separator/operator, and I=
MHO, it should be clear and distinct from namespace separator, as nested cl=
asses are a separate concept.</div><div>Maybe having a vote on the operator=
 would be enough.</div><div><br></div><div>(As a note, and this might have =
been discussed already, but I would prefer to use the term nested class ins=
tead of inner class, as in java the inner classes means non-static classes,=
 and I don&#39;t think we should go that way.)</div><div><br></div><div>--=
=C2=A0</div><div>Alex</div><div><br></div></div></div>

--00000000000064306a06308762eb--