🚀 go-pugleaf

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