Hi François,
On Thu, Jan 7, 2016 at 8:33 PM, François Laupretre <franc...@php.net> wrote:
>
> * 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.
I agree. This should be added. Reviewing this now, I also realize that
I've unintentionally worded things to suggest that only protected
*properties* (not methods) are accessible to friend classes. This is
incorrect. I will be adjusting wording to replace occurrences of
"properties" with "members". I will likely find a way of peppering
that into the examples as well.
What do you think about wording above the examples (which would
include elements quoted above) to the effect of "In addition,
protected members of Base are also accessible *through* Derived". This
would make this one larger example, with the last code block
demonstrating the rule you've described.
>
> * 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 ;).
>
This is interesting. I'm going to need to think on this a bit more but
I understand what you're saying. If included, I want to have a good
example of when I would grab for this. Additionally, we can always
leave ourselves open to this in the future as well. I'm neither for or
against this right now. I'm going to reserve further comment here for
now. If you have an application of this property in-mind, I am
interested.
>
> * In the RFC Impact / To Reflection API chapter, I think there's a
> copy/paste error. 'Trait' should probably be replaced with 'Friend'.
>
I've amended this in v0.2.1. Indeed, it is a copy/paste error from the
documentation regarding how ReflectionClass supports query on attached
Traits.
>
> * 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,
>
I agree. I left it in for discussion to see if I got exactly that
feedback, haha. There are a lot of details, already, in explaining the
feature and its properties. Near the tail-end of the document, the
reader probably is at "information overload".
The chapter on combining friendship types is easily removed as it
really doesn't add anything non-obvious. I think it would be
reasonable to remove examples from other future work and pare down
from there. I wonder if it is valuable (or not) to justify the future
scope rather than simply list future work that could be done. In fact,
this chapter started out as a simple bullet-ed list.
>
> * 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.
>
You're the third person to make a similar comment regarding striking
that balance. I'm glad to get the feedback as this is definitely new
waters for me. I am confident in the decision to disallow friend
access to private members and believe that is the best decision for
this RFC. I'll remove the additional voting choice.
>
> 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.
>
François, I very much appreciate your suggestions and look forward to
discussing this more.
Thanks,
-Dustin
--
Dustin Wheeler | Software Developer
NC State University
m: mdwhe...@ncsu.edu | w: 5-9786
"If you don't know where you're going, it's easy to iteratively not get there."
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
