*One more detail : I wouldn't set the 'friend' information on the same line as the class declaration.*
I agree, it can look horrible to read, and the way to use the "friend" syntax as the way that we currently "use" traits can be an interesting idea. Geolim4 2015-11-02 15:42 GMT+01:00 guilhermebla...@gmail.com < guilhermebla...@gmail.com>: > Hi, > > One thing that should be worth mentioning is that my approach of private > classes is decoupled in 2 parts. > > The first one as the ability to prevent instantiation outside of namespace > and sub-namespaces. The second is the ability to access protected members, > which matches your wish of friend classes nicely. > > However, I could not even tackle the second part without discussing and > agreeing on the first one, so I limited the scope of my wish in order to > simplify overall RFC phase. > > Regards, > On Nov 2, 2015 7:17 AM, "François Laupretre" <franc...@php.net> wrote: > >> Hi Georges, >> >> Le 01/11/2015 17:04, georges a écrit : >> >>> Hi php internals, >>> >>> I recently discovered the "friendship concept" in c++ and i really love >>> the concept. >>> And i wonder if the php internals would be interested to implements it in >>> the next 7.x major version. >>> >>> >> You may be interested by an article I wrote some weeks ago about adapting >> the 'friendship' concept to PHP ( >> http://tekwire.net/joomla/projects/ideas/php-friend). IMO, we should >> enable friendship from classes and/or namespaces, with and without >> inheritance, giving four cases : class, class and descendants, namespace, >> namespace and sub-namespaces. >> >> One more detail : I wouldn't set the 'friend' information on the same >> line as the class declaration. First reason is that it already contains >> 'extends' and 'implements' stances. 2nd reason is that the information is >> not required by the compiler to start compiling the class body. So, >> 'friend' lines can be part of the class body. >> >> Use cases go well beyond test classes. There are many cases where you >> need to access methods and/or even whole classes from a set of known >> locations, but don't want to make them public. Today, the only way is to >> use protected access but it implies class inheritance which, often, is not >> an option. An example is symfony using the '@internal' tag to mark >> class/properties/methods which mustn't be accessed from the outside of >> symfony (see >> http://symfony.com/doc/current/contributing/code/bc.html#using-our-classes). >> Information is better than nothing but a way to enforce access restrictions >> would be welcome. >> >> About Guilherme's proposal : it seems fine but, IMHO, the 'friend' >> concept includes it, is easier to implement, and goes much further. >> >> Regards >> >> François >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >>
