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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
