Russell Gold <goldr@inet.bis.adp.com> writes
>> But it is not. Inheritable friendship is a natural extension of
>> normal friendship (for tightly coupled classes) to tightly
>> coupled hierarchies.
>
>Except that hierarchies are necessarily open, so making a
>hierarchy a friend means that the original class becomes open to
>classes which were never imagined by its author.  You can never
>guarantee that a "tightly coupled hierarchy" will remain tightly
>coupled.  AFAIK there is no prohibition on making multiple members
>of the same hierarchy friends to the same class.  Doing this allows
>the original author to restrict access to only those members of the
>hierarchy which should have that access.

Why is everybody so obsessed with friend security? They are not for this
(read Strojstroup [sp?]).

>> In my project (that spawned the question) base class builds a
>> certain graph and derived classes decompose it in different ways
>> using helper objects
>> from other hierarchies. Nobody except those objects (and original
>> object tree, of course) has any business to that graph.
>
>So make each of those classes friends of the graph.
But this implies that we must have a closed list of all helper objects
which breaks the design (I want to be able to easily snap together
different approaches/algorithms -- evev if they are in different DLLs).
Similarly, in iostreams/streambufs trees, are you saying that each
streambuf must have a complete list of all streams?

>OR, you can use a little trick within the confines of the language.
[....]
Which is not very neat, IMHO...

            Bye                            Genie
--
-----------------------------------------------------------------------
Eugene V. Radchenko              Research associate, Computer Chemistry
E-mail: eugene@qsar.chem.msu.su                   Fax: +7-(095)939-0290
Ordinary mail:     Chair of Organic Chemistry, Department of Chemistry,
                         Moscow State University, 119899 Moscow, Russia
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 I don't think anyone on the C++ standards committee believes that all
 C++ programs should be strictly conforming.
                           Fergus Henderson, moderator of comp.std.c++



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

clamage@Eng.Sun.COM (Steve Clamage) writes:
>In article AFVop7nqs7@qsar.chem.msu.su, "Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:
[...]
>>I think we should allow inheritable friendship (probably in addition to
>>current non-inheritable one). Anyway, we are not creating the Pentagon
>>security system and thus should not be much afraid of deriving Spy from
>>TrustedUser. Especially considering that otherwise all ends in making this
>>data public.
>
>I don't see much difference between allowing friendship to be inherited
>and making all class members public. The purpose of access control is
>not to hide implementation details from other programmers, because it
>does not do that. The purpose is more to prevent other parts of the
>program from depending on implementations details as opposed to depending
>only on the public interface.
>
>If friendship is inheritable, you cannot know what functions have access to
>the implementation details of the class. That means that you cannot change
>those details. You might as well make everything public. The effect on
>program design and maintenance is comparable.

But it is not. Inheritable friendship is a natural extension of normal
friendship (for tightly coupled classes) to tightly coupled hierarchies.
One possible example is the streambuf/iostreams hierarchies.
In my project (that spawned the question) base class builds a certain graph
and derived classes decompose it in different ways using helper objects
from other hierarchies. Nobody except those objects (and original
object tree, of course) has any business to that graph.

               Best regards                      Genie

--
-----------------------------------------------------------------------
Eugene V. Radchenko              Research associate, Computer Chemistry
E-mail: eugene@qsar.chem.msu.su                   Fax: +7-(095)939-0290
Ordinary mail:     Chair of Organic Chemistry, Department of Chemistry,
                         Moscow State University, 119899 Moscow, Russia
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 I don't think anyone on the C++ standards committee believes that all
 C++ programs should be strictly conforming.
                           Fergus Henderson, moderator of comp.std.c++
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In <AFwV3Hn027@qsar.chem.msu.su>, "Eugene Radchenko" <eugene@qsar.chem.msu.su>
writes:
>But it is not. Inheritable friendship is a natural extension of normal
>friendship (for tightly coupled classes) to tightly coupled hierarchies.

Exactly.  And, not only have I considered, I have begged for it
on bended knee.  I frequently encounter the tightly coupled
hierarchy situation and it would REALLY make my life easier
and my code cleaner.

I suggested once that the keyword "friends" should indicate that
the friendship could be inherited and "friend" would indicate
that it is non-inheritable.  And it is NOT the same thing as making
the attributes public.  It is the same thing as making them
protected in another hierarchy.


Michael Lee Finney
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

mfinney@inmind.com writes:

>In <AFwV3Hn027@qsar.chem.msu.su>, "Eugene Radchenko"
><eugene@qsar.chem.msu.su> writes:
>>But it is not. Inheritable friendship is a natural extension of normal
>>friendship (for tightly coupled classes) to tightly coupled hierarchies.

>Exactly.  And, not only have I considered, I have begged for it
>on bended knee.  ...

>And it is NOT the same thing as making
>the attributes public.  It is the same thing as making them
>protected in another hierarchy.

Please notice that I did not say inherited friendship is the same
as making the members public. I said the effect on program design
and maintenance is the same.

If friendship is inherited, you cannot know what functions will
depend on the details of the private parts of the class. You cannot
know whether the unknown writers of these unknown functions will
get right all the inter-relationships among the private parts.
Since you don't know what programs will break if you make any changes
to the private parts, and you have no assurance of the correctness of
the use of these private members by unknown functions, you lose nothing
by making them public. By making them public, you avoid the false
sense of security which the "private" label seems to confer.

The point of making members private is that you have complete
knowledge of who has access to them. If you need or want to make a
change, you know exactly who will be affected. If you allow friendship
to be inherited, you lose that knowledge, and private status
provides no advantage.

Perhaps you can provide an example where inheritable friendship
gives a distinct advantage over making the members public. Bear
in mind that people you don't know about will be depending in
ways you don't know about on the private details of the class.
--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

|> I suggested once that the keyword "friends" should indicate that

class X {
#ifdef X_FRIENDS
   X_FRIENDS;
#endif
public:
..
};

The above hack should let you develop a tightly-coupled hierarchy with
minimal fuss until closure can be applied and the final friend declaration
inserted in its place.

In my opinion a tightly-coupled framework must be finite a-priori.  I can't
reconcile this requirement with that of inherited friendship.

--
John Hickin      Nortel Technology, Montreal, Quebec
(514) 765-7924   hickin@bnr.ca
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Inheirated friends could be thought of as a notational alternative of class
member functions.  Its used like that for operators at times.
There isn't any 'this', but access with given to all parameters of that class.

There would be public, protected and private friends.  They would inheirate
like methods.  The strangeness comes from things like a private friend
which could only be called from the class itself or another  private friend.

Ken Walter

* All the above is hearsay and the opinion of nobody in particular
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article AFVop7nqs7@qsar.chem.msu.su, "Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:

>Has anyone proposed/considered the inheritable friendship in addition to
>the current one? Suppose the following design (non-template version for
>brevity): ...

>I think we should allow inheritable friendship (probably in addition to
>current non-inheritable one). Anyway, we are not creating the Pentagon
>security system and thus should not be much afraid of deriving Spy from
>TrustedUser. Especially considering that otherwise all ends in making this
>data public.

I don't see much difference between allowing friendship to be inherited
and making all class members public. The purpose of access control is
not to hide implementation details from other programmers, because it
does not do that. The purpose is more to prevent other parts of the
program from depending on implementations details as opposed to depending
only on the public interface.

If friendship is inheritable, you cannot know what functions have access to
the implementation details of the class. That means that you cannot change
those details. You might as well make everything public. The effect on
program design and maintenance is comparable.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

>>>>> "SC" == Steve Clamage <clamage@Eng.Sun.COM> writes:

SC> In article AFVop7nqs7@qsar.chem.msu.su, "Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:
>> Has anyone proposed/considered the inheritable friendship in addition to
>> the current one?

SC> I don't see much difference between allowing friendship to be inherited
SC> and making all class members public. The purpose of access control is
SC> not to hide implementation details from other programmers, because it
SC> does not do that. The purpose is more to prevent other parts of the
SC> program from depending on implementations details as opposed to depending
SC> only on the public interface.

I do not support Eugene's proposal (friendship granted to a class
_and classes derived from it_), but I have a problem with your
argumentation.

IMHO, you make an assumption (commonly made) about the use of access
control beyond its "objective" semantics. Namely, access control is
often used to separate "interface" from "implementation".

Well, this view is problematic:

- There is an other way to support this separation in C++, inheritance
  from abstract classes. This other way is sufficient, and far
  superior: as you note, access control does not hide the
  implementation; inheritance does, and therefore guarrantees that
  clients of abstract interfaces do not depend on the implementation.
- Friendship may still be used in abstract interfaces to support
  interface dedication. This is useful, and not supported in any other
  way by the language.

Best Regards!--
+---------------------------------------------------------------------------+
| Marc Girod - Nokia Telecommunications     Phone: +358-0-511 27703         |
| Kilo RD 4 - P.O. Box 12                     Fax: +358-0-511 27432         |
| SF-02611 Espoo 61 - Finland            Internet: marc.girod@ntc.nokia.com |
|        X.400: C=FI, A=Elisa, P=Nokia Telecom, SUR=Girod, GIV=Marc         |
+---------------------------------------------------------------------------+
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]