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: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public From: mbk@caffeine.engr.utk.edu (Matt Kennel) Subject: Re: Real OO Date: 1996/05/18 Message-ID: <4nl9fj$35m@gaia.ns.utk.edu>#1/1 X-Deja-AN: 155496595 references: <1996May16.151642.20130@merlin.hgc.edu> followup-to: comp.lang.eiffel,comp.lang.ada,comp.object organization: University of Tennessee, Knoxville and Oak Ridge National Laboratory reply-to: kennel@msr.epm.ornl.gov newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-05-18T00:00:00+00:00 List-Id: James McKim (jcm@hgc.edu) wrote: : I think Don is right in theory, but that Tucker is right in practice. : In practice I regularly run into situations in which I want : a concrete feature that provides default behavior for descendants, : but I don't want the descendants to be totally constrained by that : behavior. IOW, I'd like two distinct kinds of assertions. Perhaps what you want is to be able to inherit implementation without also inheriting interface, which in Eiffel, encompasses assertion as well as routine signatures. This is yet another reason to make such a design choice, either explicitly in your language, or in your style of class design: keep distinct 'concrete leaf classes' which serve *only* as a locus of shared implementation from 'abstract classes' which serve as specification. : Hope this helps, : -- Jim : -- : *------------------------------------------------------------------------------* : Jim McKim (860)-548-2458 Co-editor of Eiffel Outlook : Internet: jcm@hgc.edu Subscribe early and often!