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: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: doylep@ecf.toronto.edu (Patrick Doyle) Subject: Re: Separation of IF and Imp: process issue? Date: 1997/09/09 Message-ID: #1/1 X-Deja-AN: 270862391 Sender: news@ecf.toronto.edu (News Administrator) References: <33E9ADE9.4709@flash.net> X-Nntp-Posting-Host: skule.ecf Organization: University of Toronto, Engineering Computing Facility Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-09T00:00:00+00:00 List-Id: In article , Jon S Anthony wrote: > >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". I've never used Ada, so I'm not familiar with exactly what child specs are. >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? Ignorance. :-) I should find out more about Ada 95 before I continue. But let me ask you about one thing you said... P.C does not inherit anything from P. So what is the advantage of creating a child spec versus a whole new spec? >> >> 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 mean, for example, that if the spec defines some function, the body must implement this function. That's very similar to how a deferred feature in Eiffel is defined in the subclass. When I said "properties" I meant interface properties, like what functions they implement and whatever other properties Ada allows you to declare in a package spec. Whatever interfacing properties the spec declares, the body must posess. To me, this smacks of inheritance. >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). But if you take the short form and put in the word "deferred" in a few places, it becomes a deferred class. In fact, the Short tool could do this for you; the fact that it doesn't reflects the fact that short forms are meant for documentation, but they could equally well be considered to create a class which defines the specification of another class. >The notion of "implementation" in the sense of concrete >class C derived from abstract/deferred class P "implementing P" is a >different thing altogether. The way I see it, a deferred class sets forth some interface properties-- the same kinds of properties as a spec file, and more--which its subclasses must posess. To me, it's exactly the same situation between spec files and implementation files. This may, of course, just reflect my misunderstanding of Ada. I have presumed that spec files are similar to header files in C++. -PD -- -- Patrick Doyle doylep@ecf.utoronto.ca