Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129199
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------0ME6zUCzY8PKXbOPHX5PI4bs"
Message-ID: <6fe4d3dc-4ee5-4911-b695-a8d36f034143@rwec.co.uk>
Date: Tue, 11 Nov 2025 15:14:33 +0000
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] RFC: Namespace-Scoped Visibility for Methods and
 Properties
To: internals@lists.php.net
References: <e21b1992-d426-46cd-b86a-6d6a5844c934@app.fastmail.com>
 <f1f694d7-d494-45c5-a4e4-fb39809d3b67@rwec.co.uk>
 <c0bfa15e-1df2-4d87-8092-2531b2bafcb3@app.fastmail.com>
 <72f90052-fa19-415c-9f5a-ae75275fd030@rwec.co.uk>
 <b0c4ff79-08a7-ce1f-b609-8f8425e4b155@php.net>
Content-Language: en-GB
In-Reply-To: <b0c4ff79-08a7-ce1f-b609-8f8425e4b155@php.net>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------0ME6zUCzY8PKXbOPHX5PI4bs
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 11/11/2025 11:36, Derick Rethans wrote:
> On Sat, 8 Nov 2025, Rowan Tommins [IMSoP] wrote:
>
>> To spell those out, the prefix version could look like this:
>>
>> namespace Acme\AuthLib\Somewhere\Deep\In\Package;
>> // ...
>> #[NamespacePrivate('Acme\AuthLib', includeChildren: true)]
> Whatever the way to define a prefix is going to be, I disagree with that
> being done through attributes.
>
> Nowhere in the language do these annotations (yet) interfere with
> how code can be run.


The main reason my mind went in that direction is that people are 
building attributes for this in userspace already - set the actual 
visibility to public, and then use an attribute for static analysis to 
restrict it.

They also have a standard syntax for arguments, so it's easy to 
illustrate those without spending time imagining a new syntax.

But in general, I agree, a native implementation would ideally look and 
feel like it matched the existing "private" keyword.


-- 
Rowan Tommins
[IMSoP]

--------------0ME6zUCzY8PKXbOPHX5PI4bs
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 11/11/2025 11:36, Derick Rethans
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:b0c4ff79-08a7-ce1f-b609-8f8425e4b155@php.net">
      <pre class="moz-quote-pre" wrap=""><pre wrap=""
      class="moz-quote-pre">On Sat, 8 Nov 2025, Rowan Tommins [IMSoP] wrote:

</pre><blockquote type="cite" style="color: #007cff;"><pre wrap=""
      class="moz-quote-pre">To spell those out, the prefix version could look like this:

namespace Acme\AuthLib\Somewhere\Deep\In\Package;
// ...
#[NamespacePrivate('Acme\AuthLib', includeChildren: true)]
</pre></blockquote><pre wrap="" class="moz-quote-pre">Whatever the way to define a prefix is going to be, I disagree with that 
being done through attributes.

Nowhere in the language do these annotations (yet) interfere with 
how code can be run.</pre></pre>
    </blockquote>
    <p><br>
    </p>
    <p>The main reason my mind went in that direction is that people are
      building attributes for this in userspace already - set the actual
      visibility to public, and then use an attribute for static
      analysis to restrict it.</p>
    <p>They also have a standard syntax for arguments, so it's easy to
      illustrate those without spending time imagining a new syntax.</p>
    <p>But in general, I agree, a native implementation would ideally
      look and feel like it matched the existing "private" keyword.</p>
    <p><br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------0ME6zUCzY8PKXbOPHX5PI4bs--