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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID, LOTS_OF_MONEY 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: jcm@hgc.edu (James McKim) Subject: Re: Real OO Date: 1996/05/20 Message-ID: <1996May20.173709.1047@merlin.hgc.edu>#1/1 X-Deja-AN: 155791842 sender: usenet@merlin.hgc.edu (Action News Central) references: <4nl9fj$35m@gaia.ns.utk.edu> organization: The Hartford Graduate Center newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-05-20T00:00:00+00:00 List-Id: In article <4nl9fj$35m@gaia.ns.utk.edu> kennel@msr.epm.ornl.gov writes: >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. Hmmm... At first I thought these were orthogonal issues, but upon reflection I think you may be right. So class X has a feature f that has type semantics and implementation semantics. If we want class Y to be a subtype of X then any redefinition of f in Y is bound by the original type semantics. Now what happens if we want Z to be a subclass (inherit implementation of) X? I'm assuming that in Sather there is no restriction on how Z may redefine f, is that correct? And if W is intended to be both a subtype and a subclass of X then any redefinition of f must follow its original type semantics, but can implement it any old way. Yes, this is appealing.... > >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. Lost you here. Are you talking about the subtype or subclass hierarchy? If subclass, why would the leaves share implementation with their abstract ancestors? I would have expected abstract ancestors to be supertypes. If subtype, why mention the sharing of implementation at all? Good thought, -- Jim [..] -- *------------------------------------------------------------------------------* Jim McKim (860)-548-2458 Co-editor of Eiffel Outlook Internet: jcm@hgc.edu Subscribe early and often!