Re: OOD, Ada, and Inheritance

[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)]

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