# Support for friend classes

- Thread: https://externals.io/message/21469
- Original archive: https://news-web.php.net/php.internals/21469
- Started by Leon Matthews on 2006-01-10T22:37:05+00:00
- Messages: 8
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #21469 — Leon Matthews — 2006-01-10T22:37:05+00:00

URL: https://externals.io/message/21469#21469

Hi.

I'm responsible for writing unit tests for our PHP projects at work.

I would find C++ style friend classes really useful for getting at another
class's private methods.  Since we adopted PHP5 we have been using lots of
private methods to clean our interfaces up.  Great news for everyone except
me!

I'd like to be able to do something like:

class Coder
{
    friend class CoderTest;

    private static function encode()
    {
    ...
    }
}

class CoderTest
{
    $expected = ...
    $actual   = Coder::encode(...);
    if( $expected != $actual )
        ...
}

There is feature request on bugs.php.net (#34044) about this already, but no
comments.  Is there any support for this sort of thing out there?

Useful addition to PHP6 maybe, or just another
unnecessary feature? :-)

Cheers,

	Leon

---

## #21470 — Greg Beaver — 2006-01-11T04:38:12+00:00

URL: https://externals.io/message/21469#21470 · In reply to: #21469

Leon Matthews wrote:
> Hi.
> 
> I'm responsible for writing unit tests for our PHP projects at work.
> 
> I would find C++ style friend classes really useful for getting at another
> class's private methods.  Since we adopted PHP5 we have been using lots of
> private methods to clean our interfaces up.  Great news for everyone except
> me!
> 
> I'd like to be able to do something like:
> 
> class Coder
> {
>     friend class CoderTest;
> 
>     private static function encode()
>     {
>     ...
>     }
> }
> 
> class CoderTest
> {
>     $expected = ...
>     $actual   = Coder::encode(...);
>     if( $expected != $actual )
>         ...
> }

By definition, if you're accessing it from another class, then perhaps
it isn't "private" at all.  This can be more easily and intuitively
solved by using protected and CoderTest extends Coder, or just making it
public and documenting in the code where it should and should not be used.

This is one reason that "private" should be used sparingly, and perhaps
should be thought of more as "final" than as anything else - once you
declare something private, it is inaccessible.

Greg

---

## #21471 — Derick Rethans — 2006-01-11T07:29:48+00:00

URL: https://externals.io/message/21469#21471 · In reply to: #21469

> There is feature request on bugs.php.net (#34044) about this already, but no
> comments.  Is there any support for this sort of thing out there?

If you only need friends for testing the contents of static properties, 
then there are alternative ways. One solution might be to enhance 
reflection to be able to peek into those objects (or did we already 
allow this?). A second solution is:
http://derickrethans.nl/private_properties_exposed.php

regards,
Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

---

## #21473 — Sebastian Bergmann — 2006-01-11T08:51:25+00:00

URL: https://externals.io/message/21469#21473 · In reply to: #21471

Derick Rethans schrieb:
> A second solution is:
> http://derickrethans.nl/private_properties_exposed.php

 The mechanism above is emplyed by PHPUnit 3.0 to allow testing private
 and protected properties.

-- 
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

---

## #21472 — Hartmut Holzgraefe — 2006-01-11T09:06:41+00:00

URL: https://externals.io/message/21469#21472 · In reply to: #21470

Greg Beaver wrote:
> By definition, if you're accessing it from another class, then perhaps
> it isn't "private" at all. 

in C++ "friend" gives access to both "private" and "protected" ...

> This can be more easily and intuitively
> solved by using protected and CoderTest extends Coder, 

given that PHP doesn't have multiple inheritance this just doesn't
work out all the time, so this would actually be an argument *for*
"friend" in PHP

> or just making it
> public and documenting in the code where it should and should not be used.

this argument can easily be extended to "don't use the PPP stuff at all"

"friend" on the other hand is a mechanism to allow more fine grained
access control

"friend" extends PPP in a similar way as ACLs extend the unix file
access control mechanisms "user/group/others" concept ...

-- 
Hartmut Holzgraefe, Senior Support Engineer                            .
MySQL AB, www.mysql.com

---

## #21476 — Ilia Alshanetsky — 2006-01-11T14:21:19+00:00

URL: https://externals.io/message/21469#21476 · In reply to: #21469

I think we should avoid complicating an already complex OO
functionality. Borrowing concepts from other languages is fine, but to a
degree.

Ilia

---

## #21477 — Lukas Smith — 2006-01-11T14:31:48+00:00

URL: https://externals.io/message/21469#21477 · In reply to: #21476

Ilia Alshanetsky wrote:
> I think we should avoid complicating an already complex OO
> functionality. Borrowing concepts from other languages is fine, but to a
> degree.

I think the PHP real world (not the guys porting Java APIs to PHP) 
requires support binary only:
"public API"
"my break at any time API"

regards,
Lukas

---

## #21478 — Andi Gutmans — 2006-01-11T14:50:07+00:00

URL: https://externals.io/message/21469#21478 · In reply to: #21476

Yep, I agree with that. And coming from years of writing C++ I barely 
used friends and it always seemed kind of hackish to me.

At 06:21 AM 1/11/2006, Ilia Alshanetsky wrote:
>I think we should avoid complicating an already complex OO
>functionality. Borrowing concepts from other languages is fine, but to a
>degree.
>
>Ilia