Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:89093 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 91958 invoked from network); 6 Nov 2015 04:40:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Nov 2015 04:40:06 -0000 X-Host-Fingerprint: 68.118.157.39 68-118-157-39.dhcp.mdsn.wi.charter.com Received: from [68.118.157.39] ([68.118.157.39:7818] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A0/89-24765-52F2C365 for ; Thu, 05 Nov 2015 23:40:05 -0500 Message-ID: To: internals@lists.php.net References: Date: Thu, 5 Nov 2015 22:40:02 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 68.118.157.39 Subject: Re: Friend class/function From: me@stephencoakley.com (Stephen Coakley) On 11/01/2015 10:04 AM, georges wrote: > ​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. > > > ​The concept is simple: > > It would allow declared "friend"​class method/function to call a > private/protected member of an other class: > > > The syntax could be like this (for a single friendship): > > private function extractDataFromCache() friend myFriendClass1 > { > > } > > > or like this for many friendships: > > private function extractDataFromCache() friend > {myFriendClass1::method1, myFriendClass2::method1, > myFriendClass3::method1} > { > > } > > > In this way extractDataFromCache() could be called directly by method1 in > myFriendClass1 and myFriendClass2 etc.... > > Off course deep calling should not be allowed. (E.g a function inside > myFriendClass1 that will call extractDataFromCache() won't inherit the > friendship. > > Regards, > Georges > As Rowan already wrote, package / namespace visibility is the way to go here instead. Personally I found adding "friendship" in C++ to be a poor decision, since it's usually a sign of a code smell (not *always* though). There are admittedly a couple of use cases, but keeping things inside a private namespace is probably a more elegant solution. I'd support namespace visibility. +1 -- Stephen