Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129149
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sat, 08 Nov 2025 15:43:21 +0100
To: "Kamil Tekiela" <tekiela246@gmail.com>
Cc: internals@lists.php.net
Message-ID: <f17daaa6-2ae1-477d-b7f0-bd2fea239235@app.fastmail.com>
In-Reply-To: 
 <CAGBsUreR+ROHpyp5h-_gfH7m5UC-Yw9usKyzrn6aWRb6satpAA@mail.gmail.com>
References: <e21b1992-d426-46cd-b86a-6d6a5844c934@app.fastmail.com>
 <CAGBsUreR+ROHpyp5h-_gfH7m5UC-Yw9usKyzrn6aWRb6satpAA@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC: Namespace-Scoped Visibility for Methods and Properties
Content-Type: multipart/alternative;
 boundary=054858131bea4701905c7b184b8d66ed
From: rob@bottled.codes ("Rob Landers")

--054858131bea4701905c7b184b8d66ed
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sat, Nov 8, 2025, at 14:30, Kamil Tekiela wrote:
> On Sat, 8 Nov 2025 at 12:44, Rob Landers <rob@bottled.codes> wrote:
> >
> > Hello Internals,
> >
> > I=E2=80=99d like to introduce an RFC for discussion: https://wiki.ph=
p.net/rfc/namespace_visibility which proposes a new visibility modifier:=
 private(namespace).
> >
> > This idea has appeared several times in previous threads but never p=
rogressed to a formal proposal (from what I could find). My hope is that=
 with defined semantics, examples, and implementation details, we can ev=
aluate it properly and see whether there=E2=80=99s support for moving fo=
rward. Feedback is very welcome.
> >
> > Sincerely,
> >
> > Rob Landers
>=20
> I like the idea except for the name. Why not use the internal keyword
> like C# does?
>=20

Hi, thanks for the feedback.

The main reason I didn=E2=80=99t choose "internal" is that it implies so=
me broader boundary than PHP currently defines. In languages like C#/Kot=
lin/Swift, "internal" is tied to a module or assembly, not a namespace. =
PHP doesn=E2=80=99t have a formal module/package boundary today, and I r=
eally prefer not to turn this RFC into a discussion about defining one.

private(namespace) describes exactly what it does: it widens private to =
code in the same namespace and nothing beyond that. It doesn=E2=80=99t i=
mply any other boundary or hierarchy. It=E2=80=99s also consistent with =
asymmetric visibility (public(set)/private(set)/etc), without introducin=
g a new keyword.

If we ever introduce modules or packages in the future, internal could c=
ertainly be layered on top, or become syntactic sugar over private(names=
pace) =E2=80=94 or some part of it. Much like readonly is now almost syn=
tactic sugar over "public private(set)", other than the write-once restr=
iction.

For now, I=E2=80=99m aiming to focus on making internal APIs easier to e=
xpress without inventing a new packaging system.

=E2=80=94 Rob
--054858131bea4701905c7b184b8d66ed
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Sat, Nov 8, 2025, at 14:30, Kamil Tekiela wrote:</d=
iv><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On Sat, 8 Nov 202=
5 at 12:44, Rob Landers &lt;<a href=3D"mailto:rob@bottled.codes">rob@bot=
tled.codes</a>&gt; wrote:</div><div>&gt;</div><div>&gt; Hello Internals,=
</div><div>&gt;</div><div>&gt; I=E2=80=99d like to introduce an RFC for =
discussion:&nbsp;<a href=3D"https://wiki.php.net/rfc/namespace_visibilit=
y">https://wiki.php.net/rfc/namespace_visibility</a> which proposes a ne=
w visibility modifier: private(namespace).</div><div>&gt;</div><div>&gt;=
 This idea has appeared several times in previous threads but never prog=
ressed to a formal proposal (from what I could find). My hope is that wi=
th defined semantics, examples, and implementation details, we can evalu=
ate it properly and see whether there=E2=80=99s support for moving forwa=
rd. Feedback is very welcome.</div><div>&gt;</div><div>&gt; Sincerely,</=
div><div>&gt;</div><div>&gt; Rob Landers</div><div><br></div><div>I like=
 the idea except for the name. Why not use the internal keyword</div><di=
v>like C# does?</div><div><br></div></blockquote><div><br></div><div>Hi,=
 thanks for the feedback.</div><div><br></div><div>The main reason I did=
n=E2=80=99t choose "internal" is that it implies some broader boundary t=
han PHP currently defines. In languages like C#/Kotlin/Swift, "internal"=
 is tied to a module or assembly, not a namespace. PHP doesn=E2=80=99t h=
ave a formal module/package boundary today, and I really prefer not to t=
urn this RFC into a discussion about defining one.</div><div><br></div><=
div>private(namespace) describes exactly what it does: it widens private=
 to code in the same namespace and nothing beyond that. It doesn=E2=80=99=
t imply any other boundary or hierarchy. It=E2=80=99s also consistent wi=
th asymmetric visibility (public(set)/private(set)/etc), without introdu=
cing a new keyword.</div><div><br></div><div>If we ever introduce module=
s or packages in the future, internal could certainly be layered on top,=
 or become syntactic sugar over private(namespace) =E2=80=94 or some par=
t of it. Much like readonly is now almost syntactic sugar over "public p=
rivate(set)", other than the write-once restriction.</div><div><br></div=
><div>For now, I=E2=80=99m aiming to focus on making internal APIs easie=
r to express without inventing a new packaging system.</div><div><br></d=
iv><div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--054858131bea4701905c7b184b8d66ed--