Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111912
To: internals@lists.php.net
References: <CAJpLVh0K0Mkqa2RP9DLWNXbZJGqhrvJ4CTOWvAkz-7iGENWjYg@mail.gmail.com>
 <994c6693-a405-ce0f-399c-1518a7eeb321@gmail.com>
 <CAEUnE0e-xTQqQBz0U850_BF07PN-tH15yV_M8485cgdSAWtxpQ@mail.gmail.com>
Message-ID: <4dc36ca7-3af5-fb53-521a-e7a85a5b4006@gmail.com>
Date: Mon, 21 Sep 2020 22:50:34 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <CAEUnE0e-xTQqQBz0U850_BF07PN-tH15yV_M8485cgdSAWtxpQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Namespace-private class properties
From: rowan.collins@gmail.com (Rowan Tommins)

On 21/09/2020 17:13, Michael Morris wrote:
> Next thing to consider - we have the problem of having already used the
> protected keyword in PHP, and honestly I prefer PHP's interpretation of the
> word.


I think it's actually Java that's the outlier here: PHP's meaning of 
"protected" corresponds directly to C++, and to name a few I came upon 
in a quick search it's also used that way by Kotlin [1], Scala [2], C# 
[3] and Oxygene [4] - all of which use other ways to signal package 
visibility:

- Kotlin has a fourth visibility, "internal", meaning "public within 
this module"
- Scala has an interesting syntax where you can modify the visibility 
with the name of a package, as in "private[SomePackage]"
- C# adds *three* extra visibility modes: "internal", "internal 
protected", and "private protected"
- Oxygene (a language I know next to nothing about) apparently has no 
fewer than TEN modes, including both "assembly or protected" and 
"assembly and protected"


All of which I think shows two things: firstly, that there are lots of 
different ways to express this concept; and secondly, that there are a 
lot of subtle combinations that might be useful.

The C# list is particularly confusing, presumably because it's evolved 
without a coherent plan. If I'm understanding correctly, C#'s "private 
protected" corresponds to Oxygene's much clearer "assembly and 
protected", while "protected internal" corresponds to "assembly or 
protected". Considering those combinations up front might be sensible, 
even if they're not implemented at once.


If we're considering using namespaces rather than a new package concept 
for this, we potentially have a third dimension: is it private to _this 
exact namespace_, or any "child" namespace starting with the same 
prefix? Maybe something like Scala's modifier syntax might be more 
useful, for instance:

namespace Acme\Frobulator\Helpers\File;
class FileWidget {
     private[namespace] $foo; // accessible specifically in the 
"Acme\Frobulator\Helpers\File" namespace
     private[Acme\Frobulator\Helpers\File\*] $bar; // accessible in this 
namespace, and all sub-namespaces
     private[Acme\Frobulator\*] $baz; // accessible in "Acme\Frobulator" 
and all its sub-namespaces
}


[1] https://kotlinlang.org/docs/reference/visibility-modifiers.html
[2] https://www.tutorialspoint.com/scala/scala_access_modifiers.htm
[3] 
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/access-modifiers
[4] 
https://docs.elementscompiler.com/Oxygene/Members/VisibilityLevels/structs/access-modifiers


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]