Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89734
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ncsu.edu from 209.85.215.45 cause and error)
MIME-Version: 1.0
Date: Mon, 7 Dec 2015 23:48:56 -0500
Message-ID: <CADMz3wfzasH9rDp8A-5k6nO7x7Nv7wy8z05G7mDxnpC_wDwPtg@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a1140376afbe3c005265bb046
Subject: Re: [PHP-DEV] Class Friendship in PHP
From: mdwheele@ncsu.edu (Dustin Wheeler)

--001a1140376afbe3c005265bb046
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Hi,
>
> My biggest concern about supporting friend classes is the ability to
> access non-intentional to be accessed code outside of the original class'=
s
> knowledge. This by itself is very dangerous.
>

Just to clarify, the original class explicitly declares friends of itself.
There is no opportunity for friend classes to access protected members
without the original class knowing about it. It is a specific modeling
strategy used to improve encapsulation of behavior at the cost of tight
coupling between private collaborators. In addition, other properties of
friendship protect the original class from unwarranted access. The common
expression of these properties is something like: "Just because I grant you
friendship access to me doesn=E2=80=99t automatically grant your kids acces=
s to me,
doesn=E2=80=99t automatically grant your friends access to me, and doesn=E2=
=80=99t
automatically grant me access to you." In essense, it is actually a
very-safe feature and while it can be abused, surely, I wouldn't go as far
to call it very dangerous. I have seen some pretty heinous usage of traits,
but I won't condemn the feature as dangerous! :)


> I do see however package-private classes as a possibility (I actually hav=
e
> a partially running patch for that) and allowing it to access protected
> (not private) members is a second stage of my goal, so very similar to wh=
at
> your suggested, with the exception that the original class defined what c=
an
> be accessed.
>
> Regards,
>

I see package-private classes as a separate modeling concern in the same
domain of "private collaborators", personally. While package-private
classes may be used to implement friend-like behaviors in a programming
language, they do not clearly express the core intention of friendship as a
tight-coupling between a limited set of collaborators (which may, in fact,
be members of separate packages).

To be clear, I don't want to pit two features in this domain of private
collaborators against one another. I see them as 100% separate modeling
concerns; each having its own strengths and wouldn't want to see something
as useful as package-private classes be watered down to support friend-like
behaviors because it would mean losing expression of the intent: specific
targeted coupling of a few collaborators for better separation of concerns.

Thanks for your thoughts!
--=20
Dustin Wheeler | Software Developer
NC State University
m: mdwheele@ncsu.edu | w: 5-9786
"If you don't know where you're going, it's easy to iteratively not get
there."

--001a1140376afbe3c005265bb046--