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=-0.9 required=3.0 tests=BAYES_00,FROM_ADDR_WS
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 20 Nov 92 20:28:16 GMT
From: klamath.cs.washington.edu!chambers@beaver.cs.washington.edu  (Craig Chamb
ers)
Subject: Re: OOD, Ada, and Inheritance
Message-ID: <1992Nov20.202816.27409@beaver.cs.washington.edu>
List-Id: <comp.lang.ada>

In article <1992Nov20.152625.2770@cis.ohio-state.edu>, weide@elephant.cis.ohio-
state.edu (Bruce Weide) writes:
|> In article <1992Nov13.224508.18746@beaver.cs.washington.edu>
|> chambers@cs.washington.edu writes (the only response so far to my
|> request for "good" examples of the need for dynamic selection among
|> multiple implementations of the same abstraction):
|> >
|> >In my implementation of the Self compiler, I use "run-time selection
|> >among different implementation" to good effect in several data
|> >structures.  One of the simplest is a collection of parse tree classes
|> >(in C++), each for a different kind of language construct.  Simulating
|> >this in Ada would require tagged variant records or something, without
|> >behavior attached to each variant.  A more complex data structure is a
|> >control flow graph, with different classes for each kind of CFG node
|> >(e.g. add, branch, merge).  All CFG nodes support a common protocol,
|> >but with widely-varying implementations.  No node knows what kind of
|> >node is its successor or predecessor, only its interface.
|> >
|> 
|> Craig, I don't really understand this example very well as an
|> illustration of the problem at hand.  Perhaps by "multiple
|> implementations" we mean two different things?  I'm thinking of an
|> interface as defining a SINGLE abstract behavior -- not just method
|> name and parameter profile, but also a specification of that behavior
|> in implementation-neutral terms.  Any such behavior might have more
|> than one possible implementation.
|> 
|> It sounds like you might be thinking of multiple SIMILAR BUT NOT
|> IDENTICAL abstract behaviors, and considering them to be different
|> "implementations" of the same "protocol."  Is this a correct
|> assumption?
|> 
|> Cheers,
|>     -Bruce

Yes, that's what I'm describing.  I've forgotten the original question
by now, but my response was providing a concrete example for dynamic
binding and inclusion polymorphism as commonly found in OO languages.
The alternative (at least in Ada) is quite painful.  In any case, I
don't recall why you're interested in the restricted subcase of
providing multiple implementations with *identical* abstract behavior.
I'm sure it's less common and less useful than collections of
implementations with related abstract behavior.  An example of
multiple implementations with identical behavior is multiple
implementations of a key-value table (lists of pairs or hash tables);
both have the same abstract behavior but different performance
tradeoffs for large and small tables.

-- Craig Chambers