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 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: jsa@alexandria.organon.com (Jon S Anthony) Subject: Re: Separation of IF and Imp: process issue? Date: 1997/09/08 Message-ID: #1/1 X-Deja-AN: 270782876 References: <33E9ADE9.4709@flash.net> Distribution: world Organization: PSINet Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-08T00:00:00+00:00 List-Id: In article doylep@ecf.toronto.edu (Patrick Doyle) writes: > >OK, maybe the problem is I really don't know what you mean by > >"interface file". For a spec. the answer is false. You can't derive > >from it (though you can extend it in "arbitrary" ways via children) > >and there's no inheritance. > > What's the difference between extending a spec with children, and > deriving a subclass from an abstract class? This is pretty interesting. I'm a little startled that this isn't just "obvious". When you dervive a class C from a class P (abstract or otherwise), you are setting up a semantic relationship between P and C, where C inherits the properties of P. What is more, you can (if C or P are concrete) have instances of P and C. Neither of these has any meaning in the context of package P and child P.C. P.C does not inherit anything from P (it has _visibility_ into P, including private section visibility in it's private section). Neither P nor P.C define a runtime entity and in no case can you create instances of P or P.C The bodies of either are simply the implementations of the interface(s) bundled in either (the impls of operations or the types and methods on those types defined in them). This strikes me as completely different from the subclassing. Maybe a good question to ask is, why do you think they are similar? > >> Abstract base classes can accomplish this also, through multiple > >> inheritance. > > > >The point is, the things are directly related via subclassing and > >inheritance while this is not true for specs. > > As I see it, the body must have all the properties of the spec, > and perhaps more. Ada does not use the term "inheritance" for this, > but I think it's valid for Eiffel to do so. Don't you? If not, > what is it about inheritance which fails to properly model the > spec-implementation relationship? Why do you think the bodies have all the properties of the spec? I'm not even sure what this would mean. What's more it should be clear that they don't: for example, nothing has any visibility into bodies. Ada does not use "inheritance" in either the context of spec<->body relationship or parent_spec<->child_spec relationship because to do so would be extremely misleading (at best) given the typical understanding of that term in programming language design and software construction. Also, wrt the relationship between bodies and specs. Eiffel does not use this term either (that's what the "short form" is about - not inheritance). The notion of "implementation" in the sense of concrete class C derived from abstract/deferred class P "implementing P" is a different thing altogether. /Jon -- Jon Anthony OMI, Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari