From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 2 Dec 92 20:25:22 GMT From: dog.ee.lbl.gov!network.ucsd.edu!usc!zaphod.mps.ohio-state.edu!cis.ohio-st ate.edu!elephant.cis.ohio-state.edu!weide@ucbvax.Berkeley.EDU (Bruce Weide) Subject: Re: OOD, Ada, and Inheritance Message-ID: <1992Dec2.202522.2335@cis.ohio-state.edu> List-Id: In article knight@mrco.carleton.ca (Alan Knight) writes: >In <1992Nov30.230312.8279@cis.ohio-state.edu> weide@elephant.cis.ohio-state.edu (Bruce Weide) writes: >>>: Can someone give me a good >>>: example of a case where one wants to have multiple implementations for >>>: SIMILAR but NOT IDENTICAL abstract behaviors, AND for which this >>>: abstract behavior is specified formally and in implementation-neutral >>>: terms (or at least could be in principle)? ... >>>: As part of the example I would, of >> ---------------------------------- >>>: course, expect to see the abstract specification of that part of their >> ---------------------------------------------------------------------- >>>: behavior that these different implementations would all have in >> --------------------------------------------------------------- >>>: common. >> ------- > >OK, here are 3, and although I do not provide the abstract >specification I think it is clear for all of them that such a >specification could exist. Two of them are quite general, while the >third is domain-specific. Good try! But at least as I understand the I/O and matrix algebra examples it should be the case that, if you actually write the abstract specification that you claim it is "clear" could exist, you will no doubt find that the behaviors of the various multiple implementations are IDENTICAL. I'm not sure what you mean by the finite element example because I don't know enough about that application to comment intelligently. (I know, a lot of you are probably saying this applies to the other examples, too. :-) The point is that we certainly want to permit multiple implementations of the SAME abstract behavior. Alan's examples are good testimony to that. But what do we mean by "similar" abstract behavior? Without writing down precisely what behaviors we're talking about, I don't see how we can answer this question. So I again ask for examples, rephrasing the question to try to clarify the issue I'm asking about. Can someone give a good example where "slightly different" abstract behaviors ARE ACTUALLY SPECIFIED, yet where it makes sense to want to consider as EQUIVALENT various implementations that exhibit these different behaviors? And, of course, to characterize what is meant by such behaviors being "similar" ("slightly different") without being identical? Cheers, -Bruce