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

[Samuel Mize <smize@link.com>]

Patrick Doyle wrote:
> 
> In article <JSA.97Aug29152347@alexandria.organon.com>,
> Jon S Anthony <jsa@alexandria.organon.com> wrote:
> >In article <5u62es$e23$7@miranda.gmrc.gecm.com> paul.johnson@gecm.com (Paul Johnson) writes:
> >
> >> In article <EFMpCv.8uv.0.-s@inmet.camb.inmet.com>, stt@houdini.camb.inmet.com
> >> says...
> >>
> >> >The hand-written Ada package spec (or even C header) remains a far
> >> >superior interface document for a given abstraction than is anything
> >> >I have seen extracted by a tool.
> >>
> >> Then I very strongly recommend that you take a look at the
> >> short-flat form of Eiffel.
> >
> >Been there, done that.  And I'm with Tucker on this one.
> 
>   What can you do with a hand-written package spec that you can't
> do with the Eiffel tools?

I'm not familiar with Eiffel.  Let me tell you a few things we
do in Ada, and you can tell me if the tools support it or not.
I'd be quite interested to know how the short-flat extraction tool,
or the deferred class approach, address these.  NOTE: I'M NOT
SAYING THEY CAN'T, I'M ASKING HOW THEY DO IT.  Please don't
assume this is an attack; it isn't.  I'ts a request for info.

Please specify whether the practice you suggest is commonly
done.  I've listed things that I've seen done several times for
real production code.  I'm especially curious if the deferred-class
approach that Patrick Doyle suggests is a common idiom in Eiffel.

Some capabilities that are provided by Ada's separate spec/body
approach are:

* Different order of subprograms -- one order or grouping may be
  most meaningful for the interface, another for implementation.

* Unexported (local to the package) subprograms and declarations.

* Different comments -- the Ada spec usually contains comments that
  describe what facility a subprogram provides and how to use it,
  the package contains a description of its implementation details.

* Interface control and verification -- the Ada spec can be written
  and published, and other groups can code against it.  If the
  implementation or the client changes, the compiler can verify that
  they are still consistent without having to reprocess both.

* Multiple interfaces -- you can have several sub-packages that
  export subsets of a package's functionality.  In Ada 83, if
  visibility into the body (implementation) is required, these
  must all be contained in the main package's spec; in Ada 95,
  they can be separate child packages.  In either case, if you
  just want to re-package existing functionality to provide
  different views, you can provide "view" packages that rename
  elements from the main ("full-view") package.

* Multiple implementations, global, compile time -- you can have
  many implementations of your package spec, and select the best
  one for your application at compile time.  Thus, your "list"
  could have a hash table for faster lookup, or store its contents
  to disk to allow long lists of huge data items (just one in
  memory at a time), or whatever -- as long as the spec stays the
  same, the client code doesn't need to be recompiled.

* Multiple implementations, item-specific, compile time --
  Ada generics can provide a unified interface for several
  implementations of a facility.  Any logic that is common across
  all the implementations is written into the generic, while any
  code that is implementation-specific is provides as subprograms
  that are parameters to the generic.  In the worst case, the
  generic only provides a "template" that instantiations must
  follow.  For example:

    generic
      type Item is private;
      type Stack is private;
      with procedure Push (S: in out Stack; I: in out Item);
      with procedure Pop (S: in out Stack; I: in out Item);
    package Generic_Stack is
      -- exports the procedures imported
      procedure Push (S: in out Stack; I: in out Item);
      procedure Pop (S: in out Stack; I: in out Item);
    end Generic_Stack;

  This generic just encapsulates an interface.  If you write clients
  that instantiate it, and implementation packages that can be used
  to instantiate it, then you know any client can switch to any
  implementation with a simple, compile-time change to the client
  code (where it instantiates the generic).

* Multiple implementations, run time -- these are best supported in
  Ada by dispatching subprograms and tagged types, not by packaging.

Best,
Samuel Mize