🚀 go-pugleaf

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. ]