Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89038
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
To: georges <geolim4@gmail.com>, PHP Internals <internals@lists.php.net>
References: <CACjyb+z3Aenebqe4Q5_=VP2Wbs31KwTZhs_Ts-PAHDDraGoALQ@mail.gmail.com>
Message-ID: <5637540E.3070005@php.net>
Date: Mon, 2 Nov 2015 13:16:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CACjyb+z3Aenebqe4Q5_=VP2Wbs31KwTZhs_Ts-PAHDDraGoALQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Friend class/function
From: francois@php.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=)

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