Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90338
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
To: Dustin Wheeler <mdwheele@ncsu.edu>,
 PHP internals <internals@lists.php.net>
References: <CADMz3wco4JNLHQV+NvnaA5npF=hTnzp0zdB3gK+oDbL6tTDuFA@mail.gmail.com>
Message-ID: <568F11FB.10106@php.net>
Date: Fri, 8 Jan 2016 02:33:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <CADMz3wco4JNLHQV+NvnaA5npF=hTnzp0zdB3gK+oDbL6tTDuFA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Class Friendship
From: francois@php.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=)

Hi Dustin,

thanks for this nice work !

Here are some comments and thoughts :

* There is another inheritance property I didn't include in my initial 
article, and I think that should be described :

class Base {
	friend BaseFriend;
	protected $base_prop;
	static protected $base_static;
}

class Derived extends Base {
	protected $derived_prop;
	static protected $derived_static;
}

class BaseFriend {

public function display()
{
	$d = new Derived();

	var_dump($d->base_prop);	// OK
	var_dump(Derived::$base_static) // OK

	var_dump($d->derived_prop);	// Error
	var_dump(Derived::$derived_static);	// Error
}}

I try to express it with words : a friend of a base class can access the 
properties and methods of this base class through a derived instance. 
THe same for static properties and methods through a derived class. I 
know it's not very clear but the example should be better. Actually, 
that could be a sub-chapter of the 'Friendships are not inherited' property.

* After thinking more about it, I now think we should allow some sort of 
friendship inheritance but only in one way : while a Friend of Base is 
not a friend of Derived, a DerivedOfFriend class would also be a friend 
of Base (it inherits the 'friendship' property from its 'Friend' base 
class). I think this would be more natural and avoid several 
limitations. It also allows to respect the Liskov Substitution 
Principle, which is probably a good thing (but I'm not an expert there ;).

* In the RFC Impact / To Reflection API chapter, I think there's a 
copy/paste error. 'Trait' should probably be replaced with 'Friend'.

* While it's fine to explore future scope, detailing it too much brings 
the risk that people focus on this part and reject the whole RFC. That's 
just an advice because I also preferred exploring every aspects of the 
subject, but I learned that RFC readers don't need too many details, 
especially regarding future hypothetical developments. Here, you're 
proposing friendship between classes. Do you want people to reply that 
they don't like your RFC because friendship to a global function is a 
terrible thing ? I may be wrong but I think the RFC must keep the reader 
focused on the main subject. Your subject is : friend classes and 
friendship properties. The rest, like friendship to functions and 
methods, does not deserve more than a few lines, just to show that you 
thought about it. It will always be time to develop this in a future 
follow-up RFC.

* The same for 'Combinations of Class, Class Method and Namespace 
Friendship'. I think the chapter should be removed, especially because 
the syntax you use for namespaces, functions, and methods is still 
undefined. So, people may look at your example and say : 'Oh, this 
syntax is terribly ambiguous !'. ignoring your comment. You say that 
friendship may be extended to namespaces in the future. Syntax remains 
to define. Period.

* Voting choices : It's generally preferred that RFCs are as opinionated 
as possible. So, a single approve/reject vote is preferred. In the RFC, 
you explain that you chose that, unlike C++, friends access protected 
properties only, not private ones. So, there 's no reason, IMO, to vote 
for this. That's *your* RFC. People read it to get an opinion to 
approve/reject, not to make technical choices. The risk when proposing 
too many choices is to look hesitating. An RFC must find the right 
compromise between humility and self-confidence, but hesitation is not 
an option.

* About the voter's majority, I see that as a pure addition and there's 
no BC break. So, I would say that a 50%+1 majority should be enough. To 
be confirmed.

Well, I hope you won't get me wrong, I'm just trying to help and that's 
only suggestions. That's your RFC, your work, your decisions. Anyway, 
that's a very good work and I hope it will be approved.

Regards

François