Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89791
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
Reply-To: bishop@php.net
Sender: bishop.bettini@gmail.com
In-Reply-To: <CADMz3wctxkJcJ1sCoJ++WWAmPYkBKF_cM4V-S5nLT6jUqAVzfg@mail.gmail.com>
References: <CADMz3wfdBdzcNjcNHRQetRNTpDpsrCoQ4_XikRCCbwy+10CxTw@mail.gmail.com>
 <348752699.466407212.1449572494594.JavaMail.root@zimbra71-e12.priv.proxad.net>
 <CADMz3wctxkJcJ1sCoJ++WWAmPYkBKF_cM4V-S5nLT6jUqAVzfg@mail.gmail.com>
Date: Thu, 10 Dec 2015 09:44:39 -0500
Message-ID: <CAEYWF=6ea1fXhEbPj6vdqOdLwt54jQto-+kpCrH7DjLN_0oq7A@mail.gmail.com>
To: Dustin Wheeler <mdwheele@ncsu.edu>
Cc: flaupretre@free.fr, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1148db8edca2ff05268c4001
Subject: Re: [PHP-DEV] Class Friendship in PHP
From: bishop@php.net (Bishop Bettini)

--001a1148db8edca2ff05268c4001
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 10, 2015 at 12:02 AM, Dustin Wheeler <mdwheele@ncsu.edu> wrote:

>
> 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.
>

Since friendship is about visibility, and "private" is already a
well-defined term in discussions about visibility, I would avoid the term
"private" in discussions about friendship unless you actually mean "private
visibility".  To me, the nut of the solution is expressed as:

Class members declared as friend can be accessed by only those classes
explicitly listed as being collaborators.


> - I would extend the syntax to namespaces. For examples, '\MyNS\' (syntax
> to dicuss) would declare every class in the '\MyNS' namespaces or
> sub-namespaces as friends. Must support 'friend __NAMESPACE__' or somethi=
ng
> equivalent. This, coupled with a protected __construct() method would
> provide something quite similar to package-private access, but more
> extensible and powerful.
> >
>
> 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".
>

One example comes to mind.  Imagine you have a service "manager" class that
accepts an abstract "worker" class. You then have several concrete worker
implementations. It would be nice to be able to, at a namespace level, say
all these workers are friends of the manager.

Systems where you have pluggable drivers (eg databases) or lots of
collaborating objects (charting systems) would benefit from a granular way
to declare friendship.


> 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.


I think it's the other way around: a single object declares its friendship
with an entire namespace.

Looking forward to the RFC!

--001a1148db8edca2ff05268c4001--