Hi!
Almost two years ago, I opened discussion regarding my proposal to support
class friendship through a new keyword, friend. For a number of reasons
(mostly work-related; some personal) I didn't have time to move the process
forward. There were several hot-topic discussions going through the mailing
list at the time that I believed deserved more attention. I feel that my
RFC was ill-timed, perhaps. That said, we're almost two years into the
future!
I would like to re-open discussion of my RFC and get it to vote
appropriately soon.
In the previous discussion, there was on-going work to introduce
package-private classes by Guilherme. As far as I can tell that work is
stalled, pending fundamental changes to how namespaces are implemented in
PHP (https://github.com/php/php-src/pull/947#issuecomment-224912697). Like
many others, I am very excited for the possibility of package-private
classes or namespace visibility features of any kind. Even so, my personal
vision of that landscape includes class friendship as a unique, explicit
and concise expression of tight-coupling between object-oriented
collaborators. I do not feel these efforts are either-or. I believe they
both contribute to a more expressive means of specifying the relationship
between collaborators with regard to visibility.
The RFC is at:
https://wiki.php.net/rfc/friend-classes
I need to rebase my implementation against master and send a PR. I will
have that done before voting begins as it includes several test cases and I
would appreciate additional perspectives to catch edge-cases I may not have
thought of. The implementation was quite straight-forward.
Thanks!
--
Dustin Wheeler | Software Developer
NC State University
mdwheele@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get
there."
Hey Dustin,
Given the amount of use-cases (very low, so far) this feels much much
easier if just implemented in userland via Closure::call(), since the
scope of the patch complicates the class model of PHP by a whole lot.
Another simple solution is to use things such as leedavis81/altr-ego, which
already exists in userland.
Hi!
Almost two years ago, I opened discussion regarding my proposal to support
class friendship through a new keyword,friend. For a number of reasons
(mostly work-related; some personal) I didn't have time to move the process
forward. There were several hot-topic discussions going through the mailing
list at the time that I believed deserved more attention. I feel that my
RFC was ill-timed, perhaps. That said, we're almost two years into the
future!I would like to re-open discussion of my RFC and get it to vote
appropriately soon.In the previous discussion, there was on-going work to introduce
package-private classes by Guilherme. As far as I can tell that work is
stalled, pending fundamental changes to how namespaces are implemented in
PHP (https://github.com/php/php-src/pull/947#issuecomment-224912697). Like
many others, I am very excited for the possibility of package-private
classes or namespace visibility features of any kind. Even so, my personal
vision of that landscape includes class friendship as a unique, explicit
and concise expression of tight-coupling between object-oriented
collaborators. I do not feel these efforts are either-or. I believe they
both contribute to a more expressive means of specifying the relationship
between collaborators with regard to visibility.The RFC is at:
https://wiki.php.net/rfc/friend-classes
I need to rebase my implementation against
masterand send a PR. I will
have that done before voting begins as it includes several test cases and I
would appreciate additional perspectives to catch edge-cases I may not have
thought of. The implementation was quite straight-forward.Thanks!
--
Dustin Wheeler | Software Developer
NC State University
mdwheele@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get
there."