Re: OOD, Ada, and Inheritance

[cis.ohio-state.edu!elephant.cis.ohio-state.edu!weide@ucbvax.Berkeley.EDU (Bruce Weide)]

In article <knight.723417566@cunews> 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