Thank you very much for the comments, François. On Tue, Dec 8, 2015 at 6:01 AM, <flaupre...@free.fr> wrote: > > Hi, > > Thanks for this interesting and well-documented message. > > When looking at the history about class friendship, you may have seen that > the concept was globally rejected in favor of Guilherme's project of > 'package-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 and > descendants : that is allow 'protected' but keep private reserved to the > class. This way, when looking at the class code, you know that private data > 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-namespaces > as friends. Must support 'friend __NAMESPACE__' or something equivalent. > This, coupled with a protected __construct() method would provide something > quite similar to package-private access, but more extensible and powerful. > François, 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 on > 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! -- 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
