Re: Interface/Implementation (was Re: Design by Contract)

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

In article <EG7zJn.366@syd.csa.com.au>,
Don Harrison <nospam@thanks.com.au> wrote:
>
>Patrick Doyle wrote:
>
>:  Ok, let's boil this down to two questions:
>:
>:1. What is the purpose of short forms/Ada interfaces?
>
>To provide visibility information to a client and the compiler about a class's 
>exported features. That is, it documents the client relation.

Ok, I agree with that.

>By comparison, the purpose of deferred classes is to specify what functionality 
>will be provided by descendants of a class. 

...which includes visibility information.  (Just for the record.  :-)

>That is, it documents the inheritance
>relation. This purpose is orthogonal to that of visibility. 

I think this seems to be using a pretty loose definition of "orthogonal".

Inheritance can be inheritance of interface and/or inheritance of
implementation.  Interface inheritance means inheriting visibility
information.

Orthogonal means that anything achieved using one technique cannot
be achieved using the other.  But specifying implementation (ie.
the client relationship) can be accomplished by inheritance, so I'm
not clear on how these are orthogonal.  (Perhaps I'm mistaken about
what "orthogonal" means?  I'm going on recollections of a book I
read a while back.)

>We may declare, for
>example, a deferred class which exports nothing. Such a class doesn't have 
>much of client relation with client classes but does have an inheritance relation
>with its descendants.

Couldn't you also have an empty package spec?

>:2. Why can't deferred classes accomplish this purpose?
>
>The issue is clouded a bit by the fact that deferred classes *contain* 
>visibility information. So, if you attempt to emulate Ada package specs using
>deferred classes, you're not using deferred classes per se to do it, but their
>export aspects. 

Ok.  I'll go for that, because my argument all along has been that
abstract superclasses can do as much as *and more than* Ada specs.
So let's consider just the export aspects of an abstract class.  Is
there anything that they can't do which Ada specs can do?

>:If you want to look at the whole interface of a class, you can use
>:Eiffel's "short" tool to extract it.  What the short tool produces is
>:code which is, effectively, the deferred class which would correspond
>:to the effective class in question (except that it is missing the
>:word "deferred" in certain places).
>
>I disagree, the short form is not code, but documentation. As such, they 
>can't be regarded as the same thing. 

The Short tool could very easily be modified to put the word "deferred"
in the right places and produce actual code.  Does this change so
fundamentally alter the resulting file that they are now "orthogonal"
to each other?  IMO clearly it doesn't.

>:I think this still makes sense.  The short form is only missing the
>:word "deferred" (and some other trivial syntactical niceties) in the
>:appropriate places.  Add these back in, and the resulting deferred
>:class is exactly the same as the original class.  Thus, the class *is*
>:its interface.  
>
>I think there are some non-trivial, semantic niceties that make a difference. :)

Ok, we can agree to disagree on this, but either way, it seems to me
that the fact remains that there's nothing that Ada specs can do that
Eiffel's deferred classes can't do.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca