Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89780
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ncsu.edu from 209.85.217.173 cause and error)
MIME-Version: 1.0
In-Reply-To: <348752699.466407212.1449572494594.JavaMail.root@zimbra71-e12.priv.proxad.net>
References: <CADMz3wfdBdzcNjcNHRQetRNTpDpsrCoQ4_XikRCCbwy+10CxTw@mail.gmail.com>
	<348752699.466407212.1449572494594.JavaMail.root@zimbra71-e12.priv.proxad.net>
Date: Thu, 10 Dec 2015 00:02:25 -0500
Message-ID: <CADMz3wctxkJcJ1sCoJ++WWAmPYkBKF_cM4V-S5nLT6jUqAVzfg@mail.gmail.com>
To: flaupretre@free.fr
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Class Friendship in PHP
From: mdwheele@ncsu.edu (Dustin Wheeler)

Thank you very much for the comments, Fran=C3=A7ois.

On Tue, Dec 8, 2015 at 6:01 AM, <flaupretre@free.fr> wrote:
>
> Hi,
>
> Thanks  for this interesting and well-documented message.
>
> When looking at the history about class friendship, you may have seen tha=
t the concept was globally rejected in favor of Guilherme's project of 'pac=
kage-privacy'. I personnally think friend classes are a different and more =
powerful concept and, if you feel strong enough to write and defend an RFC =
and defend it, I encourage you to go on.
>

Firstly, I apologize for the time it's taken to reply.

I agree that friend classes approach a perhaps subtly different
modeling concern than do package-private / package-visibility
features. This is to say that they are not in competition as
solutions, but are different tools for expressing different object
modeling concerns that happen to share an overlapping problem-space.
In my opinion, this is a key statement to make and describe going
forward. Both of these approaches acknowledge the problem-space of
"private collaborators". "Private collaborators" itself is perhaps
loaded terminology as it happens to reuse an already-defined concept
in this domain: `private`. The intent is to be able to express an
intimate relationship between two or more classes of object for some
justifiable domain-specific modeling reason.

I do not believe there to be any "supported features" in PHP that
directly support the problem-space of private collaborators. We have,
at best, work-arounds to achieve the end goal, but at a translation
cost of having to explain "This scope-juggling I'm doing with
Closure::bind means this class is a friend." I have a desire to be
able to express that relationship directly and I see value in being
able to do so.

I want to write and defend an RFC for implementation of friend classes
in PHP for the reasons above. In addition, I believe that scoping an
RFC for friend classes somewhat tightly works quickly towards a few
outcomes:

1. Does the community and core developer team see value in private
collaborators as a concept, in general? If the RFC is scoped
appropriately, it could serve as a barometer of interest that would
validate further work on the concept (addition of class-methods and
global functions) as well as further validate implementation of
package-private classes. If the "smallest thing that could provide
value" fails miserably, that is enough data to pivot on.

2. The RFC, even if it fails, shows formal historical interest in the
feature and the feedback and references captured through the RFC
process will inform alternative implementations or alternative
approaches to the private collaboration problem. I really see that as
a win for the language and this problem space. I'm willing to defend
an RFC for friend classes in PHP for this reason alone.

>
> - I would prefer providing the same access to friend classes as parents a=
nd descendants : that is allow 'protected' but keep private reserved to the=
 class. This way, when looking at the class code, you know that private dat=
a cannot be accessed, even by friends.
>

I could not agree more with this and believe this is an extremely
healthy compromise on the concern of non-intentional access to
members. The reasons for this compromise should be expressed in any
RFC as well as documentation, in my opinion (if things get to that
point). I have already started adjusting my tests for this compromise.

>
> - I would extend the syntax to namespaces. For examples, '\MyNS\' (syntax=
 to dicuss) would declare every class in the '\MyNS' namespaces or sub-name=
spaces as friends. Must support 'friend __NAMESPACE__' or something equival=
ent. This, coupled with a protected __construct() method would provide some=
thing quite similar to package-private access, but more extensible and powe=
rful.
>

Fran=C3=A7ois, would you be willing to describe more of the reasoning
behind this? Specifically "more extensible and powerful" [for what?].
Also, I can't think of a better way to word that request, but see how
it can come across as a direct-challenge. Just want to say I'm
genuinely curious to what the intended outcome is and don't mean to
come across as "point-y".

In my opinion, class friendship is explicit. I reach for this feature
when I need to say, "Hey, you two objects; one of you is going to know
more than the rest of my system knows about this other object. I'm
doing this so that [insert domain-specific modeling concern or
justification]." In my usage, I don't know that I would use friendship
as a means to make an entire package (namespace, in PHP's case) aware
of a single object. If I had to model this concern, I would instead
look to grab some tool that implemented some sort of namespace /
package visibility.

The other thought I have is that when I go to an object that has
friended another, I want it to be clear and determined; the degree to
which I have coupled that object to collaborators through friendship.
Allowing `friend __NAMESPACE__` allows this to grow somewhat
unbounded; which... isn't the end-of-the-world by any means and I can
see where it could be applied. Currently, however, I see it as a
misapplication of the tool?

Haha, I apologize. I have a hard time finding concision sometimes. I
guess what I'm saying is that I am definitely not against this idea,
but that I'm not generally for it, yet. To me, it doesn't map as
cleanly to the goal of better encapsulation of behaviour in one object
through strategic tighter-coupling to another object. I'd like to hear
more of your thoughts to gain some perspective.

Would this be something you would consider being a candidate for
future development and exploration of the feature? I am already
planning to put class friendship to methods and global functions on
the list for future work. Having explicit class friendship, period,
would be a pretty awesome win and meet 80% of the use-case (80/20
rule-ish here). Having clear and identified opportunities for
continued effort to flesh out the feature is a good idea, I believe.
It's also a trade-off of making a small step in the feature to allow
it to settle while other features in this problem-space move forward.
In this way, we can be sure to stay consistent in the "spirit of
private collaborators" (if that isn't too wishy-washy to say). I only
ask this question because I think it can be misunderstood as a
substitution for more robust namespace-visibility features and
possibly devalue efforts in those directions; namely Guilherme's. I
see value in that work and think there's a bit of strategy to consider
here for the sake of language design. This particular extension is
*definitely* in the overlapping problem-space of these two modeling
concerns!

>
> For inheritance rules, you may be interested by a small article I wrote o=
n the subject (http://tekwire.net/joomla/projects/ideas/php-friend).
>

Yes! You might be delighted to know that the current implementation
adheres to these rules, exactly. I honestly don't know how I didn't
come across your article in gathering references. Are you amenable to
me adding it to my list of references?

Thanks to both of you for your comments thus far and I will be sending
a request for RFC karma to create an RFC in Draft. I have a lot of
information attached to that already that describes the feature itself
with examples, but also includes background information on the
feature's lifecycle in C++ (not to say we compare ourselves, but to
describe lessons learned from that community as far as the
implementation, maintenance and community-usage of the feature). I am
eager to continue working with you all on this.

Thanks!

--=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 the=
re."