Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129154 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 D3AC21ADAD3 for ; Sat, 8 Nov 2025 20:09:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1762632593; bh=RgzqoSWZC29KGahrGPvWiLemcBCsvCQY+vPiB01EpKc=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=ZxDC870rJjVyyGSCAda+V3XkEhctzznRSPWQc7jzGU8D04PET0te52e4Fc9N19sga 0AIulGR3RXbz8HogZCC9hmn0Ahu82LtHOs2aWlCSNJQwwQOTPXoqFJ7tUo45WX967L LT/K7Vr/ZSsKWB1/dJSGTaVSirAyTlszso06PuEoMjV0B3o9/ygtWXRC5iSQ7LxILJ 7FIZ91EYJR908nTK+3T2op+0d3UqUicgKEjOXo6dyofYEPNNjTwE1RtlUckYhYjOjG 291jsp5hjsTLwv+7chcR4KiMZkwIsc8YTX11WvphYyNW4m6Ioy/rDtg1wC+mHBkgCp Yy8OFeJu1HF1A== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 088931804BF for ; Sat, 8 Nov 2025 20:09:50 +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,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from fout-b2-smtp.messagingengine.com (fout-b2-smtp.messagingengine.com [202.12.124.145]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 8 Nov 2025 20:09:46 +0000 (UTC) Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfout.stl.internal (Postfix) with ESMTP id 93B561D0016F; Sat, 8 Nov 2025 15:09:41 -0500 (EST) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-12.internal (MEProxy); Sat, 08 Nov 2025 15:09:41 -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=1762632581; x= 1762718981; bh=RX07CxX3iaJtcNq7r9yrtFb7WrSL6MR1wNu0NvEUAkk=; b=i 19VYERa2NmGWiXKFDPTo732nRBCI3YYKe5gG3R6Wx3ipY76hLJEwRpR5ggRDHt+l unN930c9KH+LHOkMOVyfyw6QBFXSKQBGFk1iowgc/xXS8iEOmSv9YT9XsHLQdcb5 StpJWScequyvlNc+c/2kh0Mq605LbjWvm54kSd/PnDGDyA7fDCQRPPT+7QkBWG2Y hVFrmKFB1QSKdVK+FGIRrp1kv6RB8uzV4akoaNunaofMRol5GI9aFrR/rhqIBV9W QE2YcNHLUD5BNVxQfxclhzl9YvGW2Eksm4UEc11WZ/x1aykLq46spqiwaHtnYuk7 rNdc5eBfwBnFSb5Juk70g== 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= 1762632581; x=1762718981; bh=RX07CxX3iaJtcNq7r9yrtFb7WrSL6MR1wNu 0NvEUAkk=; b=aX3RJvpR752SGNHYlzqSq7GhMtBeGh/edbbeiJhWJRoftqC/hwy 0oQzaASEMkx4iaGiYYW28WxDbCNZC/MeI1QQq+3qnHUDuCeWtqqxN2jSmhNhGmI5 VfTGh6Ge0k1GTKf8Ze763WDnlBPN5uUkQoCIXMDp02GkyRPyZp3RrKBOCfhj1Bn4 yuNixwqcTPVhebIihKoGERL89m/VK5dz+QlbwbtqM6/SkqPSPh5vq4kqO01QEplC wsq+GZAXq3L7IOAEf0DR973uCxbkF5IrFRp59nRyBw0DW1/vej3l0wIzEIXkXAij ET/1Owbr5y2praf9DQtTXVvmh+S6H9MsDfQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdduleefgeeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnegouf hushhpvggtthfkmhhgffhomhgrihhnucdlfedtmdenucfjughrpefoggffhffvvefkjghf ufgtsegrtderreertdejnecuhfhrohhmpedftfhosgcunfgrnhguvghrshdfuceorhhosg essghothhtlhgvugdrtghouggvsheqnecuggftrfgrthhtvghrnhepffegveevgedtfffg ffdvffdtvdehueelgeevkeetffeuleeitdegkeejtedtteeknecuffhomhgrihhnpehphh hprdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mheprhhosgessghothhtlhgvugdrtghouggvshdpnhgspghrtghpthhtohepvddpmhhoug gvpehsmhhtphhouhhtpdhrtghpthhtohephhgvlhhlohesfhgrihiirghnrghkrhgrmhdr mhgvpdhrtghpthhtohepihhnthgvrhhnrghlsheslhhishhtshdrphhhphdrnhgvth X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 1EA391820054; Sat, 8 Nov 2025 15:09:41 -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: Sat, 08 Nov 2025 21:09:20 +0100 To: "Faizan Akram Dar" 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=77d22a256a664e148908b0b00b89df36 From: rob@bottled.codes ("Rob Landers") --77d22a256a664e148908b0b00b89df36 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, Nov 8, 2025, at 18:43, Faizan Akram Dar wrote: > Hi, >=20 > I like the proposal however the choice of syntax seems inconsistent.=20 >=20 > Traditionally visibility is defined by a single keyword like private, = protected, etc, each implicitly defining the scope from which the proper= ty is accessible.=20 >=20 > Aviz (PHP 8.4) added the possibility of defining the operations that c= an be performed in the given scope like (get) or (set), the scope howeve= r is still defined by the existing keywords (private for class scope and= protected for child scope).=20 > As such, I'd suggest to use a dedicated keyword for namespace level vi= sibility like "internal" or "ns-private", the operations will still be d= efined within braces ().=20 >=20 >=20 > An excerpt from future scope of aviz rfc differentiating between visib= ility and operations.=20 >=20 > > At this time, there are only two possible operations to scope: read = and write. In concept, additional operations could be added with their o= wn visibility controls. Possible examples include: > protected(&get) - Vary whether a reference to a property can be obtain= ed independently of getting the value. (Would override the set visibilit= y if used.) > private(setref) - Allows a property to be set by reference only from c= ertain scopes. >=20 > =20 > -- >=20 > =09 > Faizan Akram Dar > https://faizanakram.me >=20 >=20 > On Sat, 8 Nov 2025, 14:21 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 >> Sincerely, >>=20 >> Rob Landers Please remember to bottom post! The reason I chose private(namespace) rather than a new keyword is that = the semantics are fundamentally a widened form of private. Access is gra= nted to code in the exact same namespace and nowhere else. There's no ad= ditional scope concept beyond that. Introducing a new keyword like internal or ns-private suggests a new typ= eof boundary rather than a refinement on existing ones. In other languag= es, internal et al. is tied to a module, assembly, crate, and not a name= space. PHP doesn=E2=80=99t have a formal module boundary today, and adop= ting the term internal would imply we=E2=80=99re defining one.=20 Sidenote: When I proposed nested classes earlier this year, the conversation quick= ly shifted into what "packages" or "modules" should mean for PHP, and th= at ended up becoming a much larger debate. I=E2=80=99d like to avoid pul= ling that discussion into this RFC. It=E2=80=99s a related, but orthogon= al topic and could absolutely be explored in a *separate thread.* private(namespace) follows the same syntactic pattern introduced in asym= metric visibility: a base keyword with a parenthesised refinement. In AV= iz, the refinement controls operations (set/get) and here it refines whi= ch callers are allowed. The syntax feels familiar and doesn=E2=80=99t re= quire introducing a new keyword. If we end up introducing modules/packages in a future RFC, a dedicated k= eyword like internal could absolutely build on top of this. For now, the= goal of this RFC is to make a small, well-defined improvement that can = be improved upon in future RFCs. =E2=80=94 Rob --77d22a256a664e148908b0b00b89df36 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Sat, Nov 8, 2025, at 18:43, Faizan Akram Dar wrote:=
<= div>
Hi,

I like t= he proposal however the choice of syntax seems inconsistent. 
=

Traditionally visibility i= s defined by a single keyword like private, protected, etc, each implici= tly defining the scope from which the property is accessible. 

Aviz (PHP 8.4) added the = possibility of defining the operations that can be performed in the give= n scope like (get) or (set), the scope however is still defined by the e= xisting keywords (private for class scope and protected for child scope)= . 
As such, I'd suggest to use a dedicated k= eyword for namespace level visibility like "internal" or "ns-private", t= he operations will still be defined within braces (). 


An ex= cerpt from future scope of aviz rfc differentiating between visibility a= nd operations. 

= > At this time, there are only two possible operations to scope: read= and write. In concept, additional operations could be added with their = own visibility controls. Possible examples include:
protected(&get) - Vary whether a reference to a property can be o= btained independently of getting the value. (Would override the set visi= bility if used.)
private(setref) - Allows a prope= rty to be set by reference only from certain scopes.

 
3D""
 
Faizan Akram Dar
3D"https://"faizanakram.me


On S= at, 8 Nov 2025, 14:21 Rob Landers, <rob@bottled.codes> wrote:

Hello Internals,

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).

This idea has appeared several times in previous th= reads but never progressed to a formal proposal (from what I could find)= . My hope is that with defined semantics, examples, and implementation d= etails, we can evaluate it properly and see whether there=E2=80=99s supp= ort for moving forward. Feedback is very welcome.

Sincerely,

Rob Landers

Please remember to= bottom post!

The reason I chose private(namesp= ace) rather than a new keyword is that the semantics are fundamentally a= widened form of private. Access is granted to code in the exact same na= mespace and nowhere else. There's no additional scope concept beyond tha= t.

Introducing a new keyword like internal or n= s-private suggests a new typeof boundary rather than a refinement on exi= sting ones. In other languages, internal et al. is tied to a module, ass= embly, crate, and not a namespace. PHP doesn=E2=80=99t have a formal mod= ule boundary today, and adopting the term internal would imply we=E2=80=99= re defining one. 

Sidenote:
When= I proposed nested classes earlier this year, the conversation quickly s= hifted into what "packages" or "modules" should mean for PHP, and that e= nded up becoming a much larger debate. I=E2=80=99d like to avoid pulling= that discussion into this RFC. It=E2=80=99s a related, but orthogonal t= opic and could absolutely be explored in a separate thread.<= /div>

private(namespace) follows the same syntactic p= attern introduced in asymmetric visibility: a base keyword with a parent= hesised refinement. In AViz, the refinement controls operations (set/get= ) and here it refines which callers are allowed. The syntax feels famili= ar and doesn=E2=80=99t require introducing a new keyword.

=
If we end up introducing modules/packages in a future RFC, a = dedicated keyword like internal could absolutely build on top of this. F= or now, the goal of this RFC is to make a small, well-defined improvemen= t that can be improved upon in future RFCs.

=E2=80=94 Rob
--77d22a256a664e148908b0b00b89df36--