Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!cornell!rochester!pt.cs.cmu.edu!cadre!pitt!cisunx!fb347231
From: fb347231@cisunx.UUCP (R  Sharma)
Newsgroups: comp.lang.c++
Subject: friends & multiple inheritance (was Needed : Recommendations for C++ texts for beginner)
Message-ID: <17606@cisunx.UUCP>
Date: 18 Apr 89 20:21:44 GMT
References: <1194@ncr-sd.SanDiego.NCR.COM> <1990009@hpctdls.HP.COM> <4009@brunix.UUCP> <282@calmasd.Prime.COM> <300@odi.UUCP>
Reply-To: sharma@vax.cs.pittsburgh.edu
Organization: Univ. of Pittsburgh, Dept. of Computer Science
Lines: 70

In article <300@odi.UUCP>, dlw@odi.UUCP (Dan Weinreb) writes:
  
  > There are also some very practical reasons for not using friends.
  > What do you do if (I should say *WHEN*) the definition of the object
  > class in question changes?  How many files do you have to search
  > through to find the direct field accesses?
  
  Easy.  The friends are all explicitly mentioned in the class
  declaration, just as the function members are.  Therefore, when the
  implementation of the class changes, you go to the class definition
  and use it to find the names of all the function members and all the
  friends.  Then you check out each one, and update it as necessary.
  ...
  In fact, friends solve some tough problems in object-oriented
  programming that are left unsolved by most o-o languages.  Sometimes
  it is truly necessary to have a piece of code that is part of the
  implementation of two classes, and knows about the internals of each
  class. ...  In such a case, I find that
  usually the two classes are best considered to be "one module", in a
  sense; that is, they get maintained together as a unit, rather than
  independently.  

Wouldn't the use of multiple inheritance solve these problems, like
that implemented in Trellis/Owl or Flavors (or proposed for C++)?
 
  The multimethods of CLOS (and its antecedent, CommonLoops) are sort of
  the same thing, although scoping rules in CLOS are so different from
  those in C++ that it is somewhat hard to draw a close analogy.  

Ok.

  ... There
  is no attempt so solve the problem in Smalltalk-80; but Smalltalk-80
  shies away from another important features needed by large, serious
  o-o programs, namely multiple inheritance, so perhaps it is just their
  policy.  

(Ah, there it is.)  But multiple inheritance has been proposed for 
Smalltalk-80 in a paper by Borning&Ingalls (1982, I think), and
its implementation seems fairly straightforward.  I understand that
however, the implementation of mult. inh. in Smalltalk-80 was
not put to any negligible amount of use.  (I don't know about
Trellis/Owl or Flavors).  

Admittedly, there is some question about the semantics of multiple
inheritance.  Snyder (OOPSLA86 ?) gives a good discussion of the
problems.

In article <9207@alice.UUCP>, ark@alice.UUCP (Andrew Koenig) writes:
  In article <300@odi.UUCP>, dlw@odi.UUCP (Dan Weinreb) writes:
  
  > Students in an introductory o-o programming course are highly unlikely
  > to run into the need for functions that are friends of two classes.
  > In fact, they are unlikely to need friends at all.
  
  Imagine a linear algebra package with Matrix and Vector classes.
  A function that multiplies a Matrix and and a Vector is a logical
  candidate to be a friend of both.

Here, if not multiple inheritance, why not have class Matrix inherit
from class Vector?

Just a few thoughts,
--Ravi

-- 
        Ravi Sharma         ARPA/INTERNET:  sharma@vax.cs.pittsburgh.edu 
                                    CSNET:  sharma%pitt@relay.cs.net  
  Dept. of Computer Science          UUCP:  ...!pitt!sharma
  University of  Pittsburgh        BITNET:  RSHARMA@PITTVMS