Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.object Subject: Re: Examples of Multiple Inheritance? Message-ID: Date: 8 Dec 90 21:52:11 GMT References: <60700005@inmet> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 70 Nntp-Posting-Host: teachh In-reply-to: muller@src.umd.edu's message of 5 Dec 90 19:19:33 GMT On 5 Dec 90 19:19:33 GMT, muller@src.umd.edu (Christophe Muller) said: muller> So let's take an example for MI. This one is extracted from B. muller> Stroustrup's book (The C++ Programming Language): muller> class temporary { ... }; muller> class employee { ... }; muller> class secretary : employee { ... }; muller> class temporary_secretary : temporary, secretary { ... }; muller> class consultant : temporary : employee { ... }; muller> This example seems perfect to me. temporary_secretary IS-A true muller> temporary worker and also IS-A true secretary.. This is a perfect example of the poverty of the common understanding of the IS-A relationship instead. In what sense temporary_secretary IS-A temporary and a secretary? In the sense that the concepts of temporary and secretary are in some way united in temporary_secretary? Or in the sense that the records that describe some aspects of those concepts are somehow merged? Or in the sense that you can invoke on a temporary secretary value all the operations you can on a temporary or secretary? Not defining precisely all these nice little details generates fuzzy warm ffeling and bad engineering. OO programming is more like databases (data design!) than knowledge bases. IS-A is just an equivalence relationship. As such it can be used to build taxonomies. The really interesting questions are: 1) What is the domain of your IS-A equivalence class generator? 2) What kind of precise equivalence definition do you want in that domain? 2) What is the algebra for the generated equivalence classes? My answers for now are something like that there are at least three domains or dimensions, specification, protocol, and implementation (pragmatics is as important but not commonly recognized) over which you want to build taxonomies (partitioning entities according to the equivalence of their specification, or of their protocol, or of their implementation), and that entities you want to classify along those three dimensions are values and functions. The goal of this taxonomy business is to devise good (de)composition criteria for build composite entities in the three dimensions, so that the resulting composite exhibits "good" structural properties. Existing mechanisms like inheritance are an an appallingly poor and misleading technology in this respect; it is both unorthogonal and incomplete (it is neither orthogonal nor a base in the data design concept space). This is clearly demonstrated by all the problems in most OO languages with defining suitable algebras for combining the generated equivalence classes, which in general are extremely poor, allowing only for addition, and in the ad hoc devices used to uncouple the three dimensions, like abstract classes, a lame attempt at decoupling the IS-A operator on the domain of interfaces from the IS-A operator on the domain of implementations. And the confusion of these issues with those of dynamic and static overloding and genericity, which are quite separate. CLOS maybe, by leaving the door open for all possible solutions, and by being oh so very unconstrained and redundant, seems to me the closest to a suitable solution, only that it is so unstructured. BETA has some very interesting ideas, and so a few others. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk