Re: Friend class/function
| From: | guilhermeblanco@gmail.com | Date: | Mon, 02 Nov 2015 14:42:41 +0000 |
| Subject: | Re: Friend class/function | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-89040@lists.php.net to get a copy of this message | ||
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" <francois@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
>
>