fb347231@cisunx.UUCP (R Sharma) (04/19/89)
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