Re: Namespace-private class properties

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