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

[nospam@thanks.com.au (Don Harrison)]

Patrick Doyle wrote:

:In article <EFnrot.3K9@syd.csa.com.au>,
:Don Harrison <nospam@thanks.com.au> wrote:
:>Neil Wilson wrote:
:>
:>:Darren New <dnew@zloty.fv.com> wrote in article
:>:<5u2fhb$4t7@newshub.atmnet.net>...
:>:> I think people are complaining that one of the missed goals is 
:>:> "the ability to administratively freeze the interface while 
:>:> allowing editing/completion/bugfixing the implementation."
:>:
:>:This is acheived using deferred classes.. 
:>
:>I disagree. Deferred classes are more like Ada abstract types, IMO; short forms
:>are more like Ada interfaces.

BTW, I meant flat-short form here.

:  The point is not how analogous they are.  

Sorry, I disagree. If we're to compare Eiffel and Ada in any meaningful 
way, finding analogues *is* the point. In particular, we're after the mechanisms 
in each language that deliver the same functionality.

:The point is that freezing interface while altering the implementation can be
:achieved using deferred classes.

Sure, you *could* use it that way in some specific circumstances but it would
be misusing the mechanism, IMO, because they fulfil different roles.

The *purpose* of deferred classes is to capture high level abstract design 
which is made progressively more concrete *through inheritance* by replacing 
deferred features with effective ones. An additional role is to facilitate 
polymorphism. This *design* role is mirrored pretty much exactly (minus 
the encapsulation) by Ada's abstract tagged types.

In comparison, the purpose of Eiffel flat-short forms and Ada package specs 
is to provide a client's *view* of the exported features of a class. This view 
exists irrespective of whether or not the class's features came about through 
inheritance and irrespective of whether polymorphism is possible. 

Something which may help to see the different roles is to consider the 
situation of an effective (concrete) class inheriting from another effective 
class (and no deferred classes). Where's the interface? Clearly, it exists 
only in the flat-short form.


BTW, I've taken "completion" in Darren's post to mean actually implementing,
as opposed to stubbing. It's true that on the design side, deferred features
get effected but I assume that's not what Darren meant. 

The issue of stubbing highlights an advantage of the Eiffel approach.
If an Eiffel system is compilable, it is also executable because all effective
features will at least have a stubbed body. Due to the fact that Ada's 
interfaces are separately compilable, it's not uncommon, early in development, 
to have to create temporary (usually stubbed) implementations for other 
developer's packages in order to produce an executable. Although it's fairly
mechanical to do so, it's still an inconvenience. The same can be said of the
maintenance aspect of redundancy in Ada specs and bodies. I, personally, find
it a pain to have to keep the two in synch.

Also, if the client produces the stubbed body, as is often the case (because 
the owner is busy doing something else), the stub is less likely to reflect 
the semantic properties of the module - for example, by returning 
non-representative values.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh