Xref: utzoo comp.lang.c++:6515 comp.object:953 Path: utzoo!attcan!uunet!mcsun!sunic!tut!tukki!sakkinen From: sakkinen@tukki.jyu.fi (Markku Sakkinen) Newsgroups: comp.lang.c++,comp.object Subject: Re: Inheritance vs. Composition Message-ID: <3020@tukki.jyu.fi> Date: 16 Feb 90 13:50:18 GMT References: <10465@alice.UUCP> Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen) Organization: University of Jyvaskyla, Finland Lines: 78 In article pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes: >In article <10465@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: >> ... >But this is just syntactic sugaring. And it leads to a lot of problems >as well, like all the funny rules about multiple inheritance, and the >ambiguity between inheritance as is-a and as part-of, and so on. There is sense behind this oversimplification. However, you could go all the way and say that any programming language is just a universal Turing machine with some syntactic sugaring; it tastes better to me with at least a little sugar. >The inheritance issue is bogus and clouds the real problem, that >in sufficiently sophisticated applications you have a data >modeling and design problem of the same size and complexity as >that of a data base, and you need to apply the same conceptual >tools, and map the concepts onto ultimately contiguity or >pointers (the only ways we have in a computer to indicate a >relationship between data). That we have a limited choice in physical implementation has no bearing on what conceptual tools and models we can or should use. (Besides, there are other ways, e.g. "foreign keys".) Many people in the data base community are applying OO concepts, including inheritance. It is one of the mandatory features suggested in "The object-oriented database system manifesto", which was written by Atkinson, Bancilhon, DeWitt, Dittrich, Maier, and Zdonik for the DOOD'89 conference. >Just think that inheritance could be entirely obviated if one were >allowed to use composition with nameless members, or if a member could >be identified by any unambiguous path to it, like in PL/1. > ... >Getting rid of inheritance, and using only composition with some >sugaring to make members of members visible at the outer level, is >entirely possible. This is pretty much in line with what both Raj and Levy - "A compositional model for software reuse" and myself - "Disciplined inheritance" presented at ECOOP'89. I think both parties had at least played with the idea of calling the paper - you guessed it - "Inheritance considered harmful". > ... > I strongly believe that inheritance was invented *only* because > in Simula 67 class objects could only be accessed via references, > and 'prefixing' (as it was more correctly called) was needed as > an efficient way of concantenating object representations. The > essentially linear nature of prefixing is what causes all the > conceptual and implementation problems with MI. I agree with much of this diagnosis, although I doubt '*only*'. Incidentally, even two very new languages, Modula-3 and Oberon (the latter extremely Spartan even in other ways), seem to follow the same prefixing principle and stick confidently to single inheritance. By the way, it still holds for almost all common OOPL's that class objects can only be accessed via references. - All conceptual problems of MI don't stem from the linear nature of prefixing as far as I can see: e.g. the Flavors model looks bad to me because it doesn't preserve the integrity of the superclass parts. > Notice also that in some cases MI has actually to be implemented > using references in C++. Doesn't this point to a fundamental > problem with the concept? :-(. No, in my analysis (see the ECOOP paper) the MI _principles_ of C++ are sounder than any others I have studied. The _implementation_ of MI has evidently become cumbersome because C++ has offered the strong concept of object identity (as seen in e.g. Smalltalk) on the altar of "efficiency". Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative network address)