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."
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:
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/90311I 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."
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
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
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."
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/90311I 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
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."
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."
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."