Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129164 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 1461E1A00BC for ; Sun, 9 Nov 2025 15:07:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1762700865; bh=c500rNWXVBQTZSBZEXnGpfRJF2Z5p0n1DOWjup2QcQU=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=KhTXGndEgxce7hGGD26AWe4EXrKVDCQpRRMnT4i4qzN/7fmpFX/3IhMf5uvJ6MiwR 80i3ig+2b16hmCdQEflfSYcY4JtiL9nkFE7Z0OsYUPvJa2Q7A+T6DQiDVUAziBlkYF DSjANjdx3ZvnLQ801GF+4jTUqwedsPwmXIPvkHjSwqas/WMLAB05058O9yvOhJFwpL cqes40jp7fi+z+i95vzZsKytdDSwMczoKhJbM3MtyForklnKdgF0zfZt7U5jmhG2ZV 1AxMWbI04KBUDdXNPQWAAlIqaV6A7eD387fyKca/32kz1upZwBx+V5/jNhAz8/8gx+ 8kqhAELEwishg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D09B718004D for ; Sun, 9 Nov 2025 15:07:43 +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,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from fhigh-a1-smtp.messagingengine.com (fhigh-a1-smtp.messagingengine.com [103.168.172.152]) (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 15:07:43 +0000 (UTC) Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfhigh.phl.internal (Postfix) with ESMTP id 098F71400192; Sun, 9 Nov 2025 10:07:38 -0500 (EST) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-12.internal (MEProxy); Sun, 09 Nov 2025 10:07: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=1762700858; x= 1762787258; bh=c500rNWXVBQTZSBZEXnGpfRJF2Z5p0n1DOWjup2QcQU=; b=G awe/QiCmCMwsTL5/rpCDWJHU4t2xvFIucTVoRBcDiNCvNTZ6zIoO9P/4sIVl+hhG fvwcLV+NOZbSibnVc3srAgVPhUB3GsB3HHSH1JKpGBut6Fq/I3kr/GpLtiet5jLe 1T70d8B6EZaIkoFp0v0KXGYwEA3/gB/VQJOjMqgBM9ROSSY/1YTy4dYYclej1PKN MsJddMFqSRQRE4tMZcyxUqBSFkUOnkT8/REumiXuDLI8NhRjy04zcp70r0+O0lpy FxUFYoEPO1KcG7gycdwHwNit8JN16kxmeYfS/kDu3o7nS2ngLoV5H+b3o53B8gha xzMTLii3SX9Nte0uOXN/A== 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= 1762700858; x=1762787258; bh=c500rNWXVBQTZSBZEXnGpfRJF2Z5p0n1DOW jup2QcQU=; b=Q3iN70Nnm97pFdP7iJUZboAAg1eqU1slBDzeTpUdoXoVLkyZ1Jl ztU6cQCgosfFF93fBrFbcHV0hlYnwh5l5KZAmJ9q5eLsrVSLpaCsjV+NjNy1pXuU wGL+nQdlu83bnpSDfjElLAf2RoYSt8BK7CNbfOvx5/ji3yE/+4NsVfE3lVxub4ef FjjmisXL8BXUsw/EpIXGC24ByzJ4xz/CEZY9wYh/VchkfNRLHMND8ePWbPG51TmL N41VdpCBbYm6hujqB2uGz8HeMypArx0B2VW8tXffI58wObcJX4zEfu25bwwVgbEE wcmo4FF0q5BStd8LlwTk33CZKCZ3tHiCv9w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdduleehjeegucetufdoteggodetrf 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 6A3D41820054; Sun, 9 Nov 2025 10:07:37 -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 16:07:17 +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=bb1c2ac9dc1642a6a865efa2c4ceabef From: rob@bottled.codes ("Rob Landers") --bb1c2ac9dc1642a6a865efa2c4ceabef Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sun, Nov 9, 2025, at 10:45, Rob Landers wrote: >=20 >=20 > 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.ph= p.net/rfc/namespace_visibility which proposes a new visibility modifier:= private(namespace). >>>=20 >>> 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. >>>=20 >>>=20 >>=20 >> Nice work on this. >>=20 >>=20 >> I have one issue: >> > *Visibility hierarchy: *public < protected < private(namespace) < p= rivate >>=20 >>>=20 >> I think is not a correct view of the real problem space, as the prote= cted and private namespace scopes are separate sets that might have thin= gs 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 = for 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 = for aviz. >>=20 >> --=20 >> Alex >=20 > Hi Alex, >=20 > I think you=E2=80=99re right, treating this as a simple linear hierarc= hy is misleading. `Protected` and `private(namespace)` *are *based on di= fferent axes: >=20 > - `protected` is inheritance-based > - `private(namespace)` is namespace-based >=20 > 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 >=20 > Formally, we can consider the caller sets: >=20 > - C[public] > - C[protected] (declaring class =E2=88=AA subclasses) > - C[ns] (all code in the exact declaring namespace) > - C[private] (declaring class only) >=20 > 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] >=20 > In general, C[protected] and C[ns] are incomparable (neither is a subs= et of the other). >=20 > 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 n= ot a subset, it=E2=80=99s a compile-time error. >=20 > That yields: >=20 > - `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] >=20 > I=E2=80=99ll update the RFC to drop the linear hierarchy and update wi= th the subset rule explicitly with some examples. >=20 > =E2=80=94 Rob I=E2=80=99ve updated the RFC and implementation accordingly along with s= ome editorial changes. =E2=80=94 Rob --bb1c2ac9dc1642a6a865efa2c4ceabef Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Sun, Nov 9, 2025, at 10:45, Rob Landers wrote:


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

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

Hello Internals,

I=E2=80=99d like to introduce an RFC for discussi= on: https://wiki.php.net/rfc/namespace_visib= ility which proposes a new visibility modifier: private(namespa= ce).

This idea has appeared several times in pr= evious threads but never progressed to a formal proposal (from what I co= uld find). My hope is that with defined semantics, examples, and impleme= ntation details, we can evaluate it properly and see whether there=E2=80= =99s support for moving forward. Feedback is very welcome.


Nice work on thi= s.


I have one issue:
> Visibility = hierarchy: public < prote= cted < private(namespace) < private


=
I think is not a correct view of the real problem spac= e, as the protected and private namespace scopes are separate sets that = might have things in common but can also be distinct.

I think the correct way to model it, is= to have two hierarchies:
public < protected < private
= public < private(namespace) < private

Otherwise you can have thing= s like
`protected private(namespace)(set)`
<= div dir=3D"auto">that is unclear how it should be handled.
Can you clarify what is the right-now expected get and set all= owance for these cases:
- child classes in the sa= me namespace
- child classes in another namespace=
- non-child classes in the same namespace
<= /div>


My suggestion is to not allow mixing protected and private namesp= ace for aviz.

-- = ;
Alex

Hi Alex,

I think you=E2=80=99re right, treati= ng this as a simple linear hierarchy is misleading. Protected and private(namespace) are based on dif= ferent axes:

- protected is inheritance-based
- private(namespace) is nam= espace-based

So, for protected private(namespace):
- ch= ild class in the same namespace: read + write
- child class in= a different namespace: read-only
- non-child class in the sam= e namespace: forbidden

Formally, we can conside= r the caller sets:

- C[public]
- C[pr= otected] (declaring class =E2=88=AA subclasses)
- C[ns] (= all code in the exact declaring namespace)
- C[private] (decla= ring 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 incompara= ble (neither is a subset of the other).

For asy= mmetric 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:

- publi= c 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&= nbsp;with private(namespa= ce)(set): incomparable
- private with private(namespace)(set): C[ns] =E2=8A=88 C[priva= te]

I=E2=80=99ll update the RFC to drop the lin= ear hierarchy and update with the subset rule explicitly with some examp= les.

=E2=80=94 Rob
=

I=E2=80=99ve updated the RFC and implem= entation accordingly along with some editorial changes.

=E2=80=94 Rob
--bb1c2ac9dc1642a6a865efa2c4ceabef--