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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public From: Samuel Mize Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/09/02 Message-ID: <340C85CE.6F42@link.com>#1/1 X-Deja-AN: 269877125 References: <01bcb389$24f579d0$1c10d30a@ntwneil> <5u62es$e23$7@miranda.gmrc.gecm.com> Organization: Hughes Training Inc. Reply-To: smize@link.com Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-02T00:00:00+00:00 List-Id: Patrick Doyle wrote: > > In article , > Jon S Anthony wrote: > >In article <5u62es$e23$7@miranda.gmrc.gecm.com> paul.johnson@gecm.com (Paul Johnson) writes: > > > >> In article , 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