On 4/7/2016 8:32 PM, guilhermebla...@gmail.com wrote: > Hi, > > I was working on a private-class support for PHP an year ago, until I hit a > problem I couldn't fix myself. >
Hi, I know and I commented on the PR on GitHub some time ago. I kept the semantics of private classes exactly as you have implemented it in there. On 4/7/2016 8:32 PM, guilhermebla...@gmail.com wrote: > The situation that brought me to work on this is, as a library developer, > people reuse internal classes that are not meant to be reused outside of > library's code. Changes to its API can potentially break consumers of the > library, making upgrades hard to happen. > That is exactly my motivation as well. On 4/7/2016 8:32 PM, guilhermebla...@gmail.com wrote: > To mitigate this problem, I thought about working on two patches to the > language that could help library/application developers, self-containing > code that is not meant to be reused. They're detailed as follow: > > 1- Private-class visibility: Only classes in the same namespace (siblings) > or child ones could instantiate the class. Cloning would still be possible > outside of namespace's scope, the same to access public members. > This is what is currently 90% done in: > https://github.com/php/php-src/pull/947 > It requires changes to Zend Engine to include a start namespace and an end > namespace opcodes, allowing to locate in which scope you are. There are > failing tests that are not passing because of this right now. > > 2- Protected-class visibility: It would work the same way as private-class > visibility, but with the difference that other classes in the same > namespace/child namespaces could access protected members of the specified > protected class. > > Of course both of them would require to go through RFC writing, idea > validation, voting and performance assessment process, but it's already a > start. > All fine with the private class approach and as mentioned I kept it equal. However, the protected class approach you describe has a huge drawback: it does not apply to parent namespaces. This makes it extremely hard to organize the classes nicely, e.g. (symfony/process): namespace Process\Pipes { abstract private class AbstractPipes {} final protected class UnixPipes extends AbstractPipes {} final protected class WinPipes extends AbstractPipes {} } namespace Process { final public class Process {} } Where the process instantiates the pipes as needed. Another problem is that suddenly every class in the current and child namespaces have the ability to access protected properties. However, you might not want that because protected properties are for true childs only. Hence, we need an additional modifier that currently does not exist in order to have full control over the usage of our internals. This is what I tried to achieve with my proposal, cover the logical side of things so that we can retrofit it to PHP without any kind of BC. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
