Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111911
MIME-Version: 1.0
In-Reply-To: <CAEUnE0e-xTQqQBz0U850_BF07PN-tH15yV_M8485cgdSAWtxpQ@mail.gmail.com>
References: <CAJpLVh0K0Mkqa2RP9DLWNXbZJGqhrvJ4CTOWvAkz-7iGENWjYg@mail.gmail.com>
 <994c6693-a405-ce0f-399c-1518a7eeb321@gmail.com> <CAEUnE0e-xTQqQBz0U850_BF07PN-tH15yV_M8485cgdSAWtxpQ@mail.gmail.com>
Date: Mon, 21 Sep 2020 18:02:42 +0000
Message-ID: <CAJpLVh2H5LF0=Rjsb0mKyLqDdZPMrYw+aGUoe70tbqnMH2QPWA@mail.gmail.com>
To: Michael Morris <tendoaki@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Namespace-private class properties
From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)

2020-09-21 16:13 GMT, Michael Morris <tendoaki@gmail.com>:
> This sort of thing would be useful. Drupal and Symfony both mark methods in
> their libraries that aren't supposed to be used externally, but people do
> anyway and then they get mad at the framework developers when they decide
> to rearrange what are supposed to be internal methods.
>
> I wrote a userland assertion to enforce just this sort of thing - enforcing
> Java's notion of protected on methods otherwise marked as public. It worked
> by looking up the caller in the debug_backtrace and checking to see if the
> namespaces matched. To keep the impact of this check minimal I used
> assert() for the check so that it wouldn't bog down production (where,
> presumably, no new code would be written).
>
> Now, the above worked, but you could hack in by lying about your namespace
> in your file declaration.  Since, at the end of the day, PHP's notion of
> namespace is entirely a string replace with no other enforcement there's no
> way I can see of changing this short of fundamentally changing how PHP
> handles namespaces.  But I wonder if that should be bothered with since
> someone would have to go considerably out of their way to make a call to a
> method they weren't supposed to, and they only have themselves to blame if
> this sort of solution becomes unstable.
>
> 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. However, PHP doesn't have class scope at this time, so one
> possibility is to allow class scope to set a default scope of the unscoped
> methods and members of the class. So...
>
> public class A {
>   function foo () {} // Callable from anywhere.
> }
>
> protected class B {
>   function foo () {} // Callable only from current namespace, or any child
> namespace.
>   public function moo() {} // Callable anywhere. In effect the method
> specific scope overrides class scope.
> }
>
> private class C {
>   function foo () {} // Callable only from the same namespace, no children
> can access. This includes a extending child function from another namespace
>   protected function moo () {} // Callable from any child class regardless
> of that child's namespace.
> }
>
> That could work. Feel free to poke holes in this - I'm sure I've missed
> something.

This syntax is already used for the PR about namespace encapsulation.
Also, I think visibility always should be explicit.

Olle