From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,c52c30d32b866eae X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public From: piercarl@sabi.demon.co.uk (Piercarlo Grandi) Subject: Re: Real OO Date: 1996/05/19 Message-ID: #1/1 X-Deja-AN: 155594778 x-nntp-posting-host: sabi.demon.co.uk sender: piercarl@sabi.demon.co.uk x-disclaimer: Contents reflect my personal views only references: organization: Home's where my rucksack's reply-to: piercarl@sabi.demon.co.uk (Piercarlo Grandi) newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-05-19T00:00:00+00:00 List-Id: mbk> James McKim (jcm@hgc.edu) wrote: jcm> I think Don is right in theory, but that Tucker is right in jcm> practice. In practice I regularly run into situations in which I jcm> want a concrete feature that provides default behavior for jcm> descendants, but I don't want the descendants to be totally jcm> constrained by that behavior. IOW, I'd like two distinct kinds of jcm> assertions. >>> On 18 May 1996 19:46:59 GMT, mbk@caffeine.engr.utk.edu (Matt Kennel) >>> said: mbk> Perhaps what you want is to be able to inherit implementation mbk> without also inheriting interface, which in Eiffel, encompasses mbk> assertion as well as routine signatures. Perhaps what you both really want is a language that allows independent reuse of interface, specification and implementation, that is the ability to assemble a class out of arbitrary parts from other classes, or simply from libraries of parts. This is not a difficult thing to have in an OO language: and I have been preaching about this on comp.object for several years now. Perhaps OO language designers don't read comp.object. :-) Actually, I think the reasons is that most OO languages are unfortunately still based, out of sheer historical accident, on the unfortunate ``prefixing'' model of reuse pioneered in SIMULA 67. That was around twenty five years ago, though -- but then there are still very recognizable traces of FORTRAN in many current popular languages. mbk> This is yet another reason to make such a design choice, either mbk> explicitly in your language, or in your style of class design: keep mbk> distinct 'concrete leaf classes' which serve *only* as a locus of mbk> shared implementation from 'abstract classes' which serve as mbk> specification. In existing languages, yes, there is no alternative; but it is an abuse of the ``class'' name. A class, strictly speaking, being the encapsulated implementation of an ADT, has all three of interface, implementation and specification, and an ``abstract class'' is not a class. I know it is a popular term, but let me object :-) that it is just another opportunity for the unwary/unweary to be tripped by terminology: an awful lot of people, as seen in this very newsgroup, take monikers seriously, even when they are obviously entirely unrelated to the concept they label (as, famously, in ``Object Oriented Programming''). In this respect ``class interface definition'' or perhaps just ``interface definition'' is a much better term than ``abstract class''. However, let me add that I don't criticize you too much for using it: its use is ingrained, it is even part of the official terminology of some popular languages.