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: 4 Dec 92 20:49:17 GMT From: cis.ohio-state.edu!elephant.cis.ohio-state.edu!weide@ucbvax.Berkeley.EDU (Bruce Weide) Subject: Re: OOD, Ada, and Inheritance Message-ID: <1992Dec4.204917.18188@cis.ohio-state.edu> List-Id: In article knight@mrco.carleton.ca (Alan Knight) writes: > >At a guess, I would say that "similar" abstract behaviours are those >that can be viewed as the same at some level of abstraction, but >differ when viewed at others. For example, you say that the matrix >implementations would have identical abstract behaviour, but a great >many of them would give (usually slightly) different answers. For some >applications, these differences would be very significant, for others >they might not be. Both levels of abstraction could still be >implementation-neutral. > Maybe we're making progress now... But first I repeat the question that promoted Alan's response: "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." It is possible to write down the behavior of procedures, etc., that manipulate what we might call "computational reals." Computational reals can be modeled formally as ordinary (mathematical) real numbers. Now one might insist on exact answers from the operations on these objects, and end up with an unimplementable specification. Or one might write that the answers given by the operations are within some tolerances of the abstract mathematical answers, as Alan proposes above. Even if you want to do the former, you can consider this to be a special case of the latter. The tolerances are PARAMETRICALLY defined in the abstract specification, so you can just let these tolerances = 0 if you always want exact answers and don't care if the thing can be implemented. So when do two implementations of computational reals behave INDENTICALLY? SIMILARLY? Here's one possible answer: They behave IDENTICALLY when they are correct implementations of the specification for the same tolerances (parameters); any such implementations should be functionally indistinguishable in any client program. They behave SIMILARLY when they are correct implementations of the specification for different tolerances (parameters). More questions now arise from Alan's answer: The same applies >to a linked-list implementation with an end-of-list that is of a >separate class rather than just being null. > These examples surely require some specs for further discussion. Our formal mathematical specifications for lists and trees don't include anything like this vocabulary (e.g., end-of-list as a separate class?). We can have any number of implementations of each abstraction and they behave identically. So I guess I just don't understand the problem here without seeing the abstract specification of behavior that causes the difficulties. Cheers, -Bruce