Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80166
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <002b01d02879$17ce3c10$476ab430$@tekwire.net>
References: <002b01d02879$17ce3c10$476ab430$@tekwire.net>
Date: Mon, 5 Jan 2015 02:05:27 +0100
Message-ID: <CADyq6s+F0nEYZDV8Lkb=KrhLbHa6kpXW4OkhkHYU4NBX3coWiA@mail.gmail.com>
To: francois@tekwire.net
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04426a606b5c06050bdd4a61
Subject: Re: [PHP-DEV] Friend classes revived
From: ocramius@gmail.com (Marco Pivetta)

--f46d04426a606b5c06050bdd4a61
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5 January 2015 at 00:49, Fran=C3=A7ois Laupretre <francois@tekwire.net> =
wrote:

> Hi,
>
> I know the subject was discussed years ago, and it was decided not to
> implement 'friend class' declarations (see
> https://bugs.php.net/bug.php?id=3D34044).
>
> But the discussions occurred ten years ago, and things (and people) may b=
e
> different now.
>
> Unfortunately, there is no easy-to-use and fast solution for this yet. Mo=
st
> projects have asked for such a feature for years but, till now, they stil=
l
> have to rely on a big warning in the documentation. Some, like symfony,
> also
> add an '@internal' tag in their phpdoc block. This can be checked in an I=
DE
> but that's information, not access restriction.
>
> IMHO, such a feature would be a valuable addition for PHP 7. If you agree=
,
> I
> will write an RFC.
>
> The feature I was thinking about would be globally similar to C++ friend
> classes, except that a PHP friend class would have access to protected
> resources, but not private ones (private would remain private).
>
> The inheritance rules would be similar to C++ rules (adapted from Wikiped=
ia
> as it originally includes access to private resources) :
>
> * Friendships are not symmetric =E2=80=93 If class A is a friend of class=
 B, class
> B
> is not automatically a friend of class A.
>
> * Friendships are not transitive =E2=80=93 If class A is a friend of clas=
s B, and
> class B is a friend of class C, class A is not automatically a friend of
> class C.
>
> * Friendships are not inherited =E2=80=93 A friend of class Base is not
> automatically a friend of class Derived and vice versa; equally if Base i=
s
> a
> friend of another class, Derived is not automatically a friend and vice
> versa.
>
> * Access due to friendship is inherited =E2=80=93 A friend of Derived can=
 access
> the
> protected members of Derived that were inherited from Base (simpler than
> the
> C++ rule as friend classes and derived classes have the same access
> rights).
>
> Another idea would be to base access restriction on namespaces, but, IMO,
> namespaces would not bring the precision we need : each class needs to
> define which classes are accepted as 'friends'.
>
> Please comment.
>
> Regards,
>
> Fran=C3=A7ois
>

There is no need for friend classes in order to support this kind of
feature (see
http://ocramius.github.io/blog/accessing-private-php-class-members-without-=
reflection/
)

Except for voodoo-cases (AOP frameworks and such) I don't see much of a
use-case here.

If you need to sync up properties between two classes you can do so by
simply using closures, as I described above.

Otherwise, making properties `public` and marking them as `@internal DO NOT
TOUCH THIS!` is perfectly fine, and doesn't need language-level
restrictions IMO.

If you need this sort of feature, consider looking at the recently
discussed https://github.com/php/php-src/pull/947, which is really much
more useful and less magic :-)

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--f46d04426a606b5c06050bdd4a61--