Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89040
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5637540E.3070005@php.net>
References: <CACjyb+z3Aenebqe4Q5_=VP2Wbs31KwTZhs_Ts-PAHDDraGoALQ@mail.gmail.com>
	<5637540E.3070005@php.net>
Date: Mon, 2 Nov 2015 09:42:41 -0500
Message-ID: <CAFp73Xs3b5ETNnj1mUi6+RbaGc7vU_aHkCa0PHDUy7Y+B6r_EQ@mail.gmail.com>
To: francois <francois@php.net>
Cc: georges <geolim4@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133151e23a67a05238fca16
Subject: Re: [PHP-DEV] Friend class/function
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--001a1133151e23a67a05238fca16
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C3=A7ois Laupretre" <francois@php.net> wrote:

> Hi Georges,
>
> Le 01/11/2015 17:04, georges a =C3=A9crit :
>
>> =E2=80=8BHi php internals,
>>
>> I recently discovered =E2=80=8Bthe "friendship concept" in c++ and i rea=
lly love
>> the concept.
>> And i wonder if the php internals would be interested to implements it i=
n
>> 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 lin=
e
> 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 nee=
d
> 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 protect=
ed
> access but it implies class inheritance which, often, is not an option. A=
n
> 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-classe=
s).
> Information is better than nothing but a way to enforce access restrictio=
ns
> would be welcome.
>
> About Guilherme's proposal : it seems fine but, IMHO, the 'friend' concep=
t
> includes it, is easier to implement, and goes much further.
>
> Regards
>
> Fran=C3=A7ois
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a1133151e23a67a05238fca16--