Re: Separation of IF and Imp: process issue?

[doylep@ecf.toronto.edu (Patrick Doyle)]

In article <JSA.97Sep8150207@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>
>In article <EG4Mry.L2C@ecf.toronto.edu> 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