Hi, I was working on a private-class support for PHP an year ago, until I hit a problem I couldn't fix myself. Now I have some more expertise of what I could do to resolve it, but I still didn't start on rebase/update of patch yet. However, I'd like to describe my line of thinking here, so people can debate about it even without me working on an updated patch yet. It's a preliminary work that needs to happen before people spend time on a patch, that will later be transformed into an RFC.
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. 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. Regards, On Thu, Apr 7, 2016 at 2:05 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > Fleshgrinder wrote on 07/04/2016 18:35: > >> I would like to change above definition for properties since the*var* >> deprecation was voted negative: >> >> # Properties >> private := limited to the current class >> protected := limited to the current and child classes >> var := limited to the current assembly >> public := global >> > > I'm not convinced of the value of reusing the keyword in this way. To me, > there is nothing in the term "var" that means "slightly less than public", > and if we want to have package/assembly/whatever visibility, we should > reserve a new keyword for that use. > > Meanwhile, it might be worth checking the list archives for previous > discussions of package visibility; I know it has come up a couple of times > recently, in various forms, so it would be good not to repeat the same > points again and again. > > Regards, > -- > Rowan Collins > [IMSoP] > -- Guilherme Blanco Lead Architect at E-Block
