> Setting aside difficulty of implementation, I'm coming around to the idea, > though I think you could simplify it by cordoning off an entire namespace. > E.g.: > > A namespace at least two deep (e.g. \A\B\) may be marked 'protected' (by some > method TBD). Classes and functions declared in a protected namespace can only > be accessed from methods or functions inside the same namespace, or in > ancestor namespaces. > > E.g., if \Foo\Internal\ is protected, access of its classes/functions must > originate from classes/functions defined in \Foo\, \Foo\Internal\, or > \Foo\Internal\*. > > This would allow something like nested classes, but obviously with a lot more > flexibility. > > In practice, plugin code sitting in, say, \MyPlugin\ could freely access > \Framework\SomeClass, but not \Framework\Internal\SomeClass.
This would solve the problem of internal classes, but these are the least interesting part, imho - The methods and properties are much more interesting, hence my new approach in response to Fabians response, where I drop the concept of internal classes. Please refer to that. > > I see some value there, but there's tons of questions remaining and how to to > implement the damn thing... > > Steve Clay -Jens -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
