Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129177 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 6C7831A00BC for ; Sun, 9 Nov 2025 19:43:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1762717400; bh=XAMeLJpMTxaa1xH6SKNmguOGmLCVHIcLRdU9aPNgp6I=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=eMkxHWGCbHTKpoDz16VtYBPxO7Fmp7dFFeIlp/mI7lrrXpTcUHD+PdxZ9qrgr6RUi Bb7dOgxryqLj3rtNY9ZjC1ARIqDFUqeqnbo19OU4TO+/BWuNeRODYw/UuFeP/EbSc2 ySf5KeWO94lKfiZUbwGmO74rLwEuRjeorYpv2bW6eo4F5zA4zZb7DgCQMku8pF9nEs gSYZENsBVcGnz/oGJrZg1FGzIPoMgDord5S+ofBzbOgixRWfuMSIYWPsf0FingD8rP +rWYeSMY5URYPivUFrrPMIbbNap7g42gHKAapZsvy+134rqYUE6ww1gV3V24mnbt0P SxEnnzak/6qgw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 2BD1418004D for ; Sun, 9 Nov 2025 19:43:19 +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.9 required=5.0 tests=BAYES_20,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 fhigh-b8-smtp.messagingengine.com (fhigh-b8-smtp.messagingengine.com [202.12.124.159]) (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 19:43:18 +0000 (UTC) Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfhigh.stl.internal (Postfix) with ESMTP id 244297A00B2; Sun, 9 Nov 2025 14:43:13 -0500 (EST) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-12.internal (MEProxy); Sun, 09 Nov 2025 14:43:13 -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=1762717392; x= 1762803792; bh=Ofs1Cr7t+ykzgloNcs+AZ26dQAO30hLuUH1dIVIAQck=; b=V 2uj2fojOmmKGCmzRGu4ZiYjyh5OurC+zfBRk+vB7I6qC56Gk/Pqb8PXEJJGOl/qS CC8zbPpfXuHBdOIYWl9O5L8ohEcn+fB5+ChpXoQx9BTxBNxNdAXaAWofpI0ETg6d 2rAPR5hMu+IEsjG3EKCrrxDytDFefUzu/psBaVzyG7ObEil7KvIX+biLN4IcNtR1 b9fYkarnneryqGNfv3AD77O5z9Xzdtk6DDZiwo1gW+pYRe6JRIbPS08DoyEhnr1n ApajDDz4E7ADfV93MHdx6AKWyCYb+eWq9W9IjIBK69a4I/0kahjaNqt7p6Cp7ucD ILI03EVDeW3nWMbBAQzUQ== 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= 1762717392; x=1762803792; bh=Ofs1Cr7t+ykzgloNcs+AZ26dQAO30hLuUH1 dIVIAQck=; b=LFe9lqdYDcl3LrWDGULrD14OWiVX1WlAhay8RUomG564k9Z3gHP XbFN48jnGO9+Zv0Q9TuD9druSc/SoE8YwyLzZ4m3CKzyqKZ7tuimqjCxejYOydfA S4moOnjYQsthm2SxUlJ5cgq42P79ER69nzcRl+N1IrwzUAxC5IyB3y8Ra2jf9O4V pRzMD+lAg0DfTY2Q79U0+hlbswtHotcEhfGsIDBJVQt/aRW8Sl4TTtOTvu9DRwXb /bbDh3zFPZHWLquFMUNc1LY18eN9vK5Wnlf0iDWx0dorRu6g81ITB4WNDI6Fz2Aa AMp9Q5gWrbmqmn45u7WimlM5KkJrRq+cLQg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdduleeivdelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgesrgdtreerredtjeenucfhrhhomhepfdftohgsucfn rghnuggvrhhsfdcuoehrohgssegsohhtthhlvggurdgtohguvghsqeenucggtffrrghtth gvrhhnpeeiueethedvvdefjefhgfeiheelheehtdfhfeekjefflefgvedvkeduteejjedt tdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehroh gssegsohhtthhlvggurdgtohguvghspdhnsggprhgtphhtthhopeefpdhmohguvgepshhm thhpohhuthdprhgtphhtthhopehtihhmsegsrghsthgvlhhsthhurdgsvgdprhgtphhtth hopegurhgvrghlvggtshesghhmrghilhdrtghomhdprhgtphhtthhopehinhhtvghrnhgr lhhssehlihhsthhsrdhphhhprdhnvght X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 6F9341820054; Sun, 9 Nov 2025 14:43:12 -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 20:41:51 +0100 To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= , =?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= Cc: "PHP internals" Message-ID: <7e17ab87-294f-450d-9afc-d23a5b919cc5@app.fastmail.com> In-Reply-To: References: Subject: Re: [PHP-DEV] RFC: Namespace-Scoped Visibility for Methods and Properties Content-Type: multipart/alternative; boundary=7411d6c3714f418f9cf7165ae647707e From: rob@bottled.codes ("Rob Landers") --7411d6c3714f418f9cf7165ae647707e Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sun, Nov 9, 2025, at 19:01, Tim D=C3=BCsterhus wrote: > Hi >=20 > On 11/9/25 16:07, Rob Landers wrote: > > I=E2=80=99ve updated the RFC and implementation accordingly along wi= th some editorial changes. >=20 > From what I see the RFC does not discuss the following at all: >=20 > class P { > protected function x() { } > } > class C extends P { > private(namespace) function x() { } > } >=20 > and vice versa: >=20 > class P { > private(namespace) function x() { } > } > class C extends P { > protected function x() { } > } >=20 > Best regards > Tim D=C3=BCsterhus Good catch! The RFC should spell out these cases directly. The behaviour= follows the same rule PHP already applies to private during inheritance: class P { protected function x() {} } class C extends P { private(namespace) function x() {} } Reducing visibility is an error. This is rejected for the same reason th= at redefining a protected method as private is rejected today: `C::x()` = would be less visible than `P::x()`. `private(namespace)` doesn=E2=80=99t introduce any new ambiguity here. T= he name even implies that visibility will be reduced and lives below pro= tected in the caller set, so reducing visibility is not allowed. class P { private(namespace) function x() {} } class C extends P { protected function x() {} } This behaves the same as overriding a private method with a protected/pu= blic one today: the parent=E2=80=99s method is private to its declaring = class, so the second example is allowed. I=E2=80=99ll update the RFC to explicitly document both of these cases s= o the inheritance rules are unambiguous. Thanks for pointing it out. =E2=80=94 Rob --7411d6c3714f418f9cf7165ae647707e Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Sun, Nov 9, 2025, at 19:01, Tim D=C3=BCsterhus wrot= e:
Hi

On 11/9/25 16:07, Rob Landers wrote:
> I=E2= =80=99ve updated the RFC and implementation accordingly along with some = editorial changes.

From what I see the RFC does= not discuss the following at all:

  =    class P {
      &nb= sp;  protected function x() { }
     = }
     class C extends P {
 = ;        private(namespace) function = x() { }
     }

an= d vice versa:

     class P = {
         private(nam= espace) function x() { }
     }
=      class C extends P {
   = ;      protected function x() { }
&nb= sp;    }

Best regards
= Tim D=C3=BCsterhus

Good catch! The= RFC should spell out these cases directly. The behaviour follows the sa= me rule PHP already applies to private during inheritance:
class P {=0A   =
 protected function x() {}=0A}=0A=0Aclass C extends P {=0A    private(na=
mespace) function x() {}=0A}

Reducing visibilit= y is an error. This is rejected for the same reason that redefining a pr= otected method as private is rejected today: C::x() would be less visible than P::x().

pr= ivate(namespace) doesn=E2=80=99t introduce any new ambiguity here= . The name even implies that visibility will be reduced and lives below = protected in the caller set, so reducing visibility is not allowed.

class =
P {=0A    private(namespace) function x() {}=0A}=0A=0Aclass C extends P {=
=0A    protected function x() {}=0A}=0A

This be= haves the same as overriding a private method with a protected/public on= e today: the parent=E2=80=99s method is private to its declaring class, = so the second example is allowed.

I=E2=80=99ll = update the RFC to explicitly document both of these cases so the inherit= ance rules are unambiguous.

Thanks for pointing= it out.

=E2=80=94 Rob --7411d6c3714f418f9cf7165ae647707e--