Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!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: OO Ada -- another way Message-ID: Date: 10 Nov 90 19:36:13 GMT References: <90@ <77500063@m.cs.uiuc.edu> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 48 Nntp-Posting-Host: odin In-reply-to: johnson@m.cs.uiuc.edu's message of 8 Nov 90 17:17:00 GMT bertrand@eiffel.UUCP: bertrand> I do not understand Professor Johnson's last comment about bertrand> creating abstract classes ``only to get around problems by the bertrand> type checker''. This does not relate to anything in my experience. On 8 Nov 90 17:17:00 GMT, johnson@m.cs.uiuc.edu said: johnson> I was not talking about programs that were impossible to type-check. johnson> I was just complaining about programs that created abstract classes johnson> with no implementation just so classes could multiply inherit from johnson> them and so have several interfaces. I consider this a bit ugly, johnson> but that is not the main problem. Arghhh. It is simply disgusting, IMNHO. johnson> The main problem is that I keep running into people who think johnson> that this is the main purpose of abstract classes, whereas the johnson> REAL purpose of abstract classes is to reuse design, including johnson> abstract algorithms. Pah. Pah. Pah. The REAL REAL :-) :-) purpose of abstract classes is to utterly confuse and complicate the life of the programmer, just like inheritance and the other ill consequences of adopting the Simula 67 OO model lock stock and barrel even if there is no need to be backwards compatible with Algol 60. johnson> Thus, abstract classes in Smalltalk almost always have useful johnson> code that is defined in terms of the undefined operations. johnson> I've seen quite a few abstract classes in C++ that don't. Why not do it properly and have *different* mechanism for abstraction over interfaces, over implementations and over specifications? Why hack to death inheritance, which is a profoundly unorthogonal concept? Overloading classes and inheritance is not just ugly, it generates all sorts of misconceptions, not just those that you describe. Consider the start of this discussion, OO in Ada. In Ada one uses generics to abstract implementations over types and procedures, not classes, and this is *good*. Indeed I am starting to reckon that classes are a bad way to attack the reuse/abstraction problem, and that other OO technologies, such as those in CLOS (or ACTOR) seem more promising. -- 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