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, LOTS_OF_MONEY,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: mbk@caffeine.engr.utk.edu (Matt Kennel) Subject: Re: Real OO Date: 1996/05/22 Message-ID: <4nvqd3$c83@gaia.ns.utk.edu>#1/1 X-Deja-AN: 156166842 references: <4nl9fj$35m@gaia.ns.utk.edu> <1996May20.173709.1047@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-22T00:00:00+00:00 List-Id: James McKim (jcm@hgc.edu) wrote: : In article <4nl9fj$35m@gaia.ns.utk.edu> kennel@msr.epm.ornl.gov writes: : >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. In Sather, if concrete class Y is a *subtype* (implying substitutability) of X then X has no implementation. You can "inherit" some part of the implementation of X from GENERIC_X_STUFF, MIXIN_HERE, and CETI_ALPHA_FIVE. It matters not for subtyping, as long as X upholds all the interfaces (supertypes) that it is supposed to. : 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. : 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? Both, but I am advocating doing them separately, as suggested by the "Design Patterns" book. : If subclass, why would the leaves share implementation with their abstract : ancestors? I would have expected abstract ancestors to be supertypes. They are. : If subtype, why mention the sharing of implementation at all? They are distinct: the "shared locus of implementation class" has nothing to do with subtyping, but is a common idiom. There is some far superior explanation on the Sather home page: http://www.icsi.berkeley.edu/~sather Look for the paper about the type & class system. : *------------------------------------------------------------------------------* : Jim McKim (860)-548-2458 Co-editor of Eiffel Outlook : Internet: jcm@hgc.edu Subscribe early and often!