Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] [VOTE] Class Friendship »

[RFC] [VOTE] Class Friendship

php.internals

Dustin Wheeler

8 years ago
Hello, I've let this RFC linger for a long time and finally wrapped up the remaining administrative items to put it to vote. This has been discussed a few times in the past: https://externals.io/message/89732 https://externals.io/message/90311 I would like to open the vote for an RFC to support Class Friendship in PHP: https://wiki.php.net/rfc/friend-classes The vote ends 2018-07-13 21:00 UTC. Thank,
-- 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."

David Rodrigues

8 years ago
I really like this. But the name "friend" sounds strange. Is not possible think about alternative names? Maybe "accessible from X" or "allow X". Em sex, 6 de jul de 2018 17:25, Dustin Wheeler <mdwheele@ncsu.edu> escreveu:

Dan Ackroyd

8 years ago
Hi Internals. To explain my vote, I'm voting no for pretty much the same reasons I listed before, http://news.php.net/php.internals/90352 The short version of which is: * 'friendship' is not a good solution for allowing restricted access to some methods. * Restricting access to some methods doesn't appear to me to be a big problem that demands to be solved at the language level with class friendship. Either solving it at a different level, or some other solution at the language level, or _just not solving it at all_, would be a better trade-off to me. If the vote doesn't approve this RFC, for people who think that allowing restricted access to some methods is a still a desired thing, there has been discussion of package level modifiers including things like visibility and type strictness. To me, a package level solution would seem to be able to avoid the downsides of 'class friendship' and give a better fitting tool to solve that problem. cheers Dan Ack

Niklas Keller

8 years ago
Hey, could you please fix the creation date in the RFC? It lists 2018-06-27, which would mean that the minimum discussion period wouldn't be over, yet, but it's actually been created somewhen last year. Regards, Niklas

Dustin Wheeler

8 years ago
On Sat, Jul 7, 2018 at 12:09 PM Niklas Keller <me@kelunik.com> wrote:
> > Hey, > > could you please fix the creation date in the RFC? It lists > 2018-06-27, which would mean that the minimum discussion period > wouldn't be over, yet, but it's actually been created somewhen last > year. >
Ugh, sorry about that! In my rush getting the voting doodle in, I updated the date as well as a matter of habit. I've updated the date to 2017-09-21, which was the date I considered the RFC text finalized. For completeness, the last call for discussion was almost 9 months ago [1]. 1: https://externals.io/message/100743 Thanks for the heads up! -Dustin
-- 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."

Yasuo Ohgaki

8 years ago
On Sat, Jul 7, 2018 at 5:26 AM Dustin Wheeler <mdwheele@ncsu.edu> wrote:
> Hello, > > I've let this RFC linger for a long time and finally wrapped up the > remaining administrative items to put it to vote. This has been > discussed a few times in the past: > > https://externals.io/message/89732 > https://externals.io/message/90311 > > I would like to open the vote for an RFC to support Class Friendship in > PHP: > > https://wiki.php.net/rfc/friend-classes > > The vote ends 2018-07-13 21:00 UTC. > >
"Friend" is powerful feature when classes are required to have "tight coupling", even if "tight coupling" is bad thing to have in general. Most obvious use case is "testing classes". Tests require tight coupling because tests have to know and test class internals to perform detailed tests. With "friend", we can remove A LOT of access methods solely for testing class. Less codes means less complexity. Having many codes for tests in production classes does not make much sense also. Having a lot of getter/setter methods for testing is pain and this fact leads developers to write inferior tests. "Friend" makes UNIT test and Contract Programming much simpler and easier. Therefore, it helps to develop more robust apps. Obvious risk is "friend abuse" where "tight coupling" isn't required nor useful. Big warning in the doc would be enough to prevent users from shooting their own foot. There are features like "friend", e.g. $GLOBALS I understand concerns, however simpler/cleaner production classes without test only methods and having detailed tests is worth to have. I would like to vote to "yes". However, RFC does not have benchmark result. Do you have some results? Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Dustin Wheeler

8 years ago
On Sat, Jul 7, 2018 at 6:46 PM Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> > I would like to vote to "yes". > However, RFC does not have benchmark result. Do you have some results? > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net > >
I have not run a benchmark on the current implementation but would be happy to (and also attach that to the results of the RFC, pass or fail). Since there really isn't a good way to test this exact behaviour against master (since it doesn't exist), do you have any ideas for a reasonable benchmark? The only added clock time should be attaching "friended" classes to the "friending" zend_class_entry and an additional runtime check for `protected` member access. What about the following: For master (control): ``` class Readable { public $property = 'foo'; } class Reader { public function read(Readable $object) { echo $object->property; } } $readable = new Readable(); $reader = new Reader(); // Time the following... for ($i = 0; $i < 10000; $i++) { $reader->read($readable); } ``` For RFC (experiment): ``` class NotReadable { friend Reader; protected $property = 'foo'; } class Reader { public function read(NotReadable $object) { echo $object->property; } } $not_readable = new NotReadable(); $reader = new Reader(); // Time the following... for ($i = 0; $i < 10000; $i++) { $reader->read($not_readable); } ``` If you have any better idea, let me know and I can move forward. Also, if there is some "standard" benchmark you'd like me to run, please let me know. 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."

Dustin Wheeler

8 years ago
On Sat, Jul 7, 2018 at 6:46 PM Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> > I would like to vote to "yes". > However, RFC does not have benchmark result. Do you have some results? > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net >
Yasuo, I have documented a benchmark based on my last comment. This benchmark could be improved through larger sample size but it looks like there is little to no difference in performance between the two. The result I determined with a sample size of 100N was a 0.000425905 second difference between `master` and `feature/friend-classes-poc` (friend branch was slower by that delta). My experiment is documented at https://gist.github.com/mdwheele/e4dce7adb7a4f523011c21de6b29f001. 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."

Dustin Wheeler

8 years ago
On Fri, Jul 6, 2018 at 4:24 PM Dustin Wheeler <mdwheele@ncsu.edu> wrote:
> > I would like to open the vote for an RFC to support Class Friendship in PHP: > > https://wiki.php.net/rfc/friend-classes > > The vote ends 2018-07-13 21:00 UTC. >
Hello, The RFC for Class Friendship failed to meet a 2/3 majority approval and has been declined. I appreciate everybody's time and consideration! 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."