Anyone considered inheritable friendship?

Thread View: comp.std.c++

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Eugene Radchenko Mon, 12 Feb 1996 16:20

#3326

Author: Eugene Radchenko
Date: Mon, 12 Feb 1996 16:20

51 lines
2694 bytes

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

  class Actor {   //performs some actions
   public:
    //define type X here
    class LittleAction {        //performs some elementary action on X
     public:
      virtual void DoIt(X *x);
      virtual ~LittleAction();
    };
   protected:
    LittleAction *doer;
    Actor(LittleAction *the_doer);
    void Perform(vector<X> &vec);
    friend class LittleAction;
    //some protected data - e.g. some cached procesed 'vec' - needed by
    //    LittleAction
  };

Here LittleAction defines abstract interface. We can implement it
differently and pass derived classes to Actor constructor. Actor and
LittleAction hierarchies must work together, LittleAction accessing some
private Actor data (which should not be accessed by other classes).
Everything is OK unless we really use OO design and derive something from
LittleAction - and oops! private data is inaccessible.
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 (that's the problem with totalitarism - too tight a regime gets
overthrown).

         Bye-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
## The careful application of terror is also a form of communication ##


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]

Re: Anyone considered inheritable friendship?

#3322

Author: Steve Clamage
Date: Mon, 12 Feb 1996 18:24

30 lines
2211 bytes

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

Re: Anyone considered inheritable friendship?

#3444

Author: Marc Girod
Date: Thu, 15 Feb 1996 17:16

43 lines
3240 bytes

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

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads