Path: news.daimi.aau.dk!news.uni-c.dk!sunic!ugle.unit.no!nac.no!eunet.no!nuug!EU.net!uunet!cs.utexas.edu!koriel!news2me.EBay.Sun.COM!engnews2.Eng.Sun.COM!olm From: olm@Eng.Sun.COM (Ole Lehrmann Madsen) Newsgroups: comp.lang.beta Subject: On why BETA does not have multiple inheritance Date: 15 Sep 1994 05:59:27 GMT Organization: Sun Microsystems Inc., Mountain View, CA Lines: 169 Message-ID: <358nrv$bpf@engnews2.Eng.Sun.COM> NNTP-Posting-Host: det.eng.sun.com X-Newsreader: NN version 6.5.0 #21 (NOV) On comp.lang.beta gzenie@neural.hampshire.edu (Garth Zenie) writes: > ................. > finally, is is true that beta doesn't have multiple inheritence? if > this is true and if any of the developers of beta are monitering this > newsgroup, i would be curious what led to that descision. > > -- garth I shall try to explain why there is no (traditional) muliple inheritance in BETA. Please note that I am not trying to argue against MI. The following is only attempting to explain why it is not in BETA. When BETA was designed we did not think that the concept of multiple inheritance was ready for being incorporated in the language. One of the main design goals for BETA was that it should be good for modelling. Most usages of MI seemed to be for pure reuse of code. I.e. a new class may be defined by inheriting from a number of classes and then redefining the parts that should differ. Often this is done without there being any conceptual relations between the new class and the ones it inherits from. We did not like that way of using inheritance. MI in BETA should be there to model classification hierachies which are non-tree structured. In practice such hierarchies are rare (my experience). What is more common is that you may want several (independent) tree-structured classification hierarchies for the same objects. A set of person objects might be classified according to their profession, nationality and religion. This gives 3 class-hierarchies. People often handle such situation using MI, but this will merge the hierarchies in a way that makes it difficult to identify the 3 hierarchies. We would like to support such indpedent classification hierarchies in BETA, but no concrete proposal exist. The various proposals for solving name conflicts and overlapping super classes, also seemed rather complex. We did not want the semantics of basic constructs to be complicated to understand. For BETA there are a number of special problmes with conflicts: 1. virtual patterns from a common super class may have conflicting bindings in the super classes: A: (# V:< A1 .... do ...; inner; ... #); B: A(# V::< A2 ... do ...; inner; ...#); C: A(# V::< A3 ... do ...; inner; ...#); D: B & C (# V:: A4 #); (The syntax 'B & C' has tentatively been used for MI in BETA) Here A2 and A3 must both be subs of A1 and A4 must be a sub of A2 and A3. (Kristine Thomsen in her PhD defined a language along these lines where virtual bindings a la BETA were handled It should be available from the Computer Science Department, Aarhus University) 2. A semantics for combining 'inner' of multiple supers must be defined. See the example above. Should B's do-part be executed before that of C or vice versa. Since we are not in favour of the ordering of superclasses being significant, we were considering the order of B and C to be non-deterministic, in the sesne that the implementation can execute B or C in any order. (The Thesis by Kristine Thomsen, also deals with combing inner and proposes a number of other alternatives. You may also take a look at: K.S. Thomsen: Inheritance on processes, exemplified on distributed termination detection, International journal of paralellel programming, pages 24-37, Nov. 1988) Finally, we have not felt an strong need to support MI in the traditional sense, since BETA has other means for handling some of the most common MI cases: In BETA you may inherit from part-objects and at the same time bind virtuals in the part-object A: (# f:< ... #) B: (# g:< ... #) C: (# ... X: @ A(# f::< (# ... #) ... #); Y: @ B(# g::< (# ... #) ... #); ... #); X and Y are singular part-objects. The virtual bindings of f and g may due to BETA's block structure refer to variables in the enclosing C-object. Consider W: ^ C The functions f and g may be invoked as W.X.f W.Y.g The difference from MI is that you have to qualify using X and Y. Some think this is inconvenient. Others thinks it is an advantage since you are explicit about name-conflicts between A and B. If you prefer writing W.f and W.g, you may define f and g functions in C and let the forardthe call to X.f and Y.g repectively. Consider V: ^A Then W.X[] -> V[] is possible, and an invocation V.f call the virtual binding of f the object X, and thereby possibly accesing/changing the state of C. To sum up this form of multiple-inheritance form part objects is very similar to non-overlapping inheritance in C++. Asa final example, consider the following well-know MI case: Window / \ WindowWitBorder WindowWithTitle \ / WindowWithTitleAndBorder In BETA this may be handled using block-structure (the exsample is due to Kasper \sterby - he has an article about this and I am sure he can supply the exact reference - kasper@iesd.auc.dk) Window: (# ... Border: (# ... #); Title: (# ... #); #); W1: @Window(# B: @Border; T: @Title #) W2: @Window(# T1,T2: @Title #) Here W1 has a border and a title, whereas W2 has no border and two titles. To sum up, we did not think that traditional MI has been worth the complications it will add to the language, since many of the MI cases acn be handled by other means. We are, however, still discussing MI, and it may end up being supported more directly. If you are inrested in more details, some of the above is also discussed in O.L. Madsen, B. Moller-Pedersen, K, Nygaard: Object-oriented programming in the BETA programming language. Addison Wesley/ACM press, 1993. ISBN 0-201-62430-3 Ole Lehrmann Madsen W: ^ C