Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129160 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 7DE941A00BC for ; Sun, 9 Nov 2025 09:45:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1762681559; bh=Kj4uPRKDKcRgRFe5gs4jDm5K2Kxdr4LGUWWey6G/UqA=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=hwFVWG6kc0GqS2GE3ROZdkXl1mWc0kSJDgos+C+gLgF8RStFyTSRkiGTopJmGNHbP QlNh4Leyr+bsWufaBHFxK0L0owymjSlFiUZXrzUPd+doq32Xt/3NXlA6CHndEruJXy XmNYHmrWNjD83LUPjZT7XlVlw6lXH4VvNzO6TcUT20nPoyZoW8X+/GhEa0zyu13n37 0L+sKck8gysQ65zm4YdSqhRWP+cTq9tYtJMj97Xm1F+2Ik2oBtBDXrc6eVpS1lRO6S Aqhewe6EX5RvP4I3hZQfhQVnDAi/sAnGOyNJfG8mScPeR/AlnOKnBSI55Qk9dVuyZV Dx9fqDohQF17Q== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id CE02618002E for ; Sun, 9 Nov 2025 09:45:54 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,T_SPF_TEMPERROR autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 9 Nov 2025 09:45:44 +0000 (UTC) Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfhigh.phl.internal (Postfix) with ESMTP id D8F791400154; Sun, 9 Nov 2025 04:45:38 -0500 (EST) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-12.internal (MEProxy); Sun, 09 Nov 2025 04:45:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm1; t=1762681538; x= 1762767938; bh=Kj4uPRKDKcRgRFe5gs4jDm5K2Kxdr4LGUWWey6G/UqA=; b=X 1eu8LEvXMmOfOcWJHl0HGw+RWMFo/i3VgAzUU7KwRNUVibO8M/fcv5/UFKONut/u aK+z7+1cW6+7Hh4f5qW81ueaZiIA5vQ6ha+/04FbVnwNI9QYvfa9m6ih6ApbgJv1 U4gRHDf/2hIcCdltK7JMoQSuD8P908wZxMo0vt9ILThLE9SqFmEWT1CNaYVZhjSJ r3PE50mYuYF/HYI3RVW1lGViblljlpnIkLXIZA7vWTvJJiqlYnQY4FsOjVnHShum O1TqkvggqlZ+YHPxcr/I8V1CyapSpdH0BFvFHDlHv19J+d94iA0tqxCAzKynUeNe FS1xwpd8TAg/PatfDqh1Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1762681538; x=1762767938; bh=Kj4uPRKDKcRgRFe5gs4jDm5K2Kxdr4LGUWW ey6G/UqA=; b=M7JUGlc2D17MJ7fjh388ehN7TLsowCPrykU6IkrEzxyoreTChhl CNrDUpvfa70HFKjflEevMWTJAUpSqXlQ8lbpgAbHuy0MCqiQ2YYfbOF3W2VgYLC8 /tSPaJCPxRq7RiLnHNYbuPdI8D9aG++K9vxfRPB1aDteP1CkdvBsdhzJCRbOchJ5 fqkO1/2yqdLgKtpWBk28DvyuuIVGyG7SFBvch+FWEmvhRBJl0z3HNCHrdtktnH1M aFVr8xcGVelVDrxiiKgc/L1uzST3WgpTtCxuXxxjJEmpbFT7YJpM0YnT1am8aULn Nj7o1TDYo8ejN6Rnd/ojMoLUfIuei5t9z9g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdduleehtdelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgesrgdtreerredtjeenucfhrhhomhepfdftohgsucfn rghnuggvrhhsfdcuoehrohgssegsohhtthhlvggurdgtohguvghsqeenucggtffrrghtth gvrhhnpeffgeevveegtdffgfffvdfftddvheeuleegveekteffueeliedtgeekjeettdet keenucffohhmrghinhepphhhphdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehrohgssegsohhtthhlvggurdgtohguvghspdhnsggp rhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegurhgvrghlvg gtshesghhmrghilhdrtghomhdprhgtphhtthhopehinhhtvghrnhgrlhhssehlihhsthhs rdhphhhprdhnvght X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 628651820054; Sun, 9 Nov 2025 04:45:38 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 X-ThreadId: AZgO4gJIj6HZ Date: Sun, 09 Nov 2025 10:45:08 +0100 To: =?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= Cc: "PHP internals" Message-ID: In-Reply-To: References: Subject: Re: [PHP-DEV] RFC: Namespace-Scoped Visibility for Methods and Properties Content-Type: multipart/alternative; boundary=e67679e2eaa147f99f70c37ed7baf411 From: rob@bottled.codes ("Rob Landers") --e67679e2eaa147f99f70c37ed7baf411 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sun, Nov 9, 2025, at 07:09, Alexandru P=C4=83tr=C4=83nescu wrote: > Hi Rob >=20 > On Sat, Nov 8, 2025, 14:46 Rob Landers wrote: >> __ >> Hello Internals, >>=20 >> I=E2=80=99d like to introduce an RFC for discussion: https://wiki.php= .net/rfc/namespace_visibility which proposes a new visibility modifier: = private(namespace). >>=20 >> This idea has appeared several times in previous threads but never pr= ogressed to a formal proposal (from what I could find). My hope is that = with defined semantics, examples, and implementation details, we can eva= luate it properly and see whether there=E2=80=99s support for moving for= ward. Feedback is very welcome. >>=20 >>=20 >=20 > Nice work on this. >=20 >=20 > I have one issue: > > *Visibility hierarchy: *public < protected < private(namespace) < pr= ivate >=20 >>=20 > I think is not a correct view of the real problem space, as the protec= ted and private namespace scopes are separate sets that might have thing= s in common but can also be distinct. >=20 > I think the correct way to model it, is to have two hierarchies: > public < protected < private > public < private(namespace) < private >=20 > Otherwise you can have things like > `protected private(namespace)(set)` > that is unclear how it should be handled. > Can you clarify what is the right-now expected get and set allowance f= or these cases: > - child classes in the same namespace > - child classes in another namespace > - non-child classes in the same namespace >=20 >=20 > My suggestion is to not allow mixing protected and private namespace f= or aviz. >=20 > --=20 > Alex Hi Alex, I think you=E2=80=99re right, treating this as a simple linear hierarchy= is misleading. `Protected` and `private(namespace)` *are *based on diff= erent axes: - `protected` is inheritance-based - `private(namespace)` is namespace-based So, for `protected private(namespace)`: - child class in the same namespace: read + write - child class in a different namespace: read-only - non-child class in the same namespace: forbidden Formally, we can consider the caller sets: - C[public] - C[protected] (declaring class =E2=88=AA subclasses) - C[ns] (all code in the exact declaring namespace) - C[private] (declaring class only) We have two partial orders: - C[public] =E2=8A=87 C[protected] =E2=8A=87 C[private] - C[public] =E2=8A=87 C[ns] =E2=8A=87 C[private] In general, C[protected] and C[ns] are incomparable (neither is a subset= of the other). For asymmetric properties, the `(set)` visibility must satisfy C[set] =E2= =8A=87 C[base]. If C[set] and C[base] are incomparable or otherwise not = a subset, it=E2=80=99s a compile-time error. That yields: - `public` with any `(set)` visibility: C[any] =E2=8A=86 C[public] - `protected` with `protected(set)` or `private(set)` only: C[private] =E2= =8A=86 C[protected] - `private(namespace)` with `private(namespace)(set)` or `private(set)` = only: C[private] =E2=8A=86 C[ns] - `private` with `private(set)` only: C[private] =E2=8A=86 C[private] - `protected` with `private(namespace)(set)`: incomparable - `private` with `private(namespace)(set)`: C[ns] =E2=8A=88 C[private] I=E2=80=99ll update the RFC to drop the linear hierarchy and update with= the subset rule explicitly with some examples. =E2=80=94 Rob --e67679e2eaa147f99f70c37ed7baf411 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Sun, Nov 9, 2025, at 07:09, Alexandru P=C4=83tr=C4=83= nescu wrote:
Hi Rob

On Sat, Nov 8, 2025, 14:46 Rob Landers <rob@bottled.codes>= wrote:







So, for p= rotected private(namespace):
- child class in the same = namespace: read + write
- child class in a different namespace= : read-only
- non-child class in the same namespace: forbidden=

Formally, we can consider the caller sets:=

- C[public]
- C[protected] (declarin= g class =E2=88=AA subclasses)
- C[ns] (all code in the ex= act declaring namespace)
- C[private] (declaring class only)

We have two partial orders:
- C[public= ] =E2=8A=87 C[protected] =E2=8A=87 C[private]
- C[pu= blic] =E2=8A=87 C[ns] =E2=8A=87 C[private]

In general, C[protected] and C[ns] are incomparable (neither is a = subset of the other).

For asymmetric properties= , the (set) v= isibility must satisfy C[set] =E2=8A=87 C[base]. If C[set] and C[ba= se] are incomparable or otherwise not a subset, it=E2=80=99s a compile-t= ime error.

That yields:

- public wit= h any (set) visibi= lity: C[any] =E2=8A=86 C[public]
- protected with protected(set) or private(set) only: C[private] =E2=8A=86= C[protected]
- private(namespace) with private(namespace)(set) or private(set) only: C[private]&= nbsp;=E2=8A=86 C[ns]
- private with private(set) only: C[private] =E2=8A=86 C[private]
- protected with private(names= pace)(set): incomparable
- private with private(namespace)(set): C[ns] =E2=8A=88 C[pri= vate]

I=E2=80=99ll update the RFC to drop t= he linear hierarchy and update with the subset rule explicitly with some= examples.

=E2=80=94 Rob --e67679e2eaa147f99f70c37ed7baf411--