Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89042
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFp73Xs3b5ETNnj1mUi6+RbaGc7vU_aHkCa0PHDUy7Y+B6r_EQ@mail.gmail.com>
References: <CACjyb+z3Aenebqe4Q5_=VP2Wbs31KwTZhs_Ts-PAHDDraGoALQ@mail.gmail.com>
 <5637540E.3070005@php.net> <CAFp73Xs3b5ETNnj1mUi6+RbaGc7vU_aHkCa0PHDUy7Y+B6r_EQ@mail.gmail.com>
Date: Mon, 2 Nov 2015 17:40:59 +0100
Message-ID: <CACjyb+zniyvySbuZAVWfc4WrqW5tXzus8Gxmk-PpSUti5GEBDw@mail.gmail.com>
To: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>
Cc: francois <francois@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1145b934f09c7d05239172b8
Subject: Re: [PHP-DEV] Friend class/function
From: geolim4@gmail.com (georges)

--001a1145b934f09c7d05239172b8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=E2=80=8B*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 guilhermeblanco@gmail.com <
guilhermeblanco@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 namespac=
e
> 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> wrot=
e:
>
>> 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 re=
ally 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 adaptin=
g
>> 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 i=
s
>> 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 n=
ot
>> 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-class=
es).
>> Information is better than nothing but a way to enforce access restricti=
ons
>> 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=C3=A7ois
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

--001a1145b934f09c7d05239172b8--