Re: OOD, Ada, and Inheritance

Re: OOD, Ada, and Inheritance

[saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!new]

In article <mmaccorm.47@fox.nstn.ns.ca> mmaccorm@fox.nstn.ns.ca (Mike Mac Corma
ck) writes:
>If Ada software is being designed using OOA and OOD, should inheritance be 
>avoided (or prohibited) in the design process, as Ada does not provide 
>inheritance? 
>

There are many projects being build in Ada that are applying OOD.
The project that I am on, the Space Station Verification and
Training Facility, is applying both OOA and OOD.  It is definitely
a non-trivial project, with an estimated total SLOC count of
2 million (I think SLOC is such a useless metric for government
projects, wouldn't "Pounds of Documentation" be more useful? :-)

Our inheritance is "manual", employing pass-through calls and
composition to simulate "real" inheritance.  This is very deliberate,
since we intend to quickly transition to Ada 9X, which will support
inheritance and run-time dispatching.  In the 30 year life of this
project, we felt that the early manual implementation of inheritance
would give bigger payoffs than choosing to ignore that feature.

It seems silly to sacrifice a design to fit in a current language.
Especially when you know that language will support those
"prohibited" features in about 2 years.


---- I can't speak for my company.  Not until I get this damn gag off!-------
David Weller,         | Space Station Training Facility: Like the real
CAE-Link,             | thing, only you can step outside for a breath
Space Technology Div. | of fresh air!
----I'm the Ultimate International Masochist: I speak Ada AND Esperanto!-----

Re: OOD, Ada, and Inheritance

[David Emery]

Ada *does* provide a limited form of inheritance, via derived types.
Ada 9X will build on this for general inheritance.  

We've 'simulated' inheritance via generics.  This was a painful
process.  

Generally, if inheritance makes sense, then use it in the design, and
'manually code' it.  If all you need is inheritance, and not
polymorphism, that's easy to do.  Polymorphism requires a lot of case
analysis, which is somewhat more painful.

Finally, you might want to consider 'Classic-Ada', which is a
pre-processor that takes an "object oriented Ada" and translates it to
legal Ada.

				dave

Re: OOD, Ada, and Inheritance

[agate!doc.ic.ac.uk!uknet!root44!hrc63!mrcu!paj]

In article <mmaccorm.47@fox.nstn.ns.ca> mmaccorm@fox.nstn.ns.ca (Mike Mac Corma
ck) writes:
>If Ada software is being designed using OOA and OOD, should inheritance be 
>avoided (or prohibited) in the design process, as Ada does not provide 
>inheritance? 

Good question.  If no-one has any other questions then class is
dismissed :-)

I recall that ADA's genericity system allows you to pass functions and
procedures as parameters in a way reminiscent of the C function
pointers (although ADA is type-safe).  I would look into the
possibility of simulating inheritance by setting up structures of
functions when objects are created.  You should be able to get single
inheritance without too much trouble.  Maybe an ADA guru can suggest
some details.

One system built in this way is the X Intrinsics library (Xt).  Its
built in C, but the principle remains the same.  Take a look at it for
an idea of what I mean.

Paul.
-- 
Paul Johnson (paj@gec-mrc.co.uk).	    | Tel: +44 245 73331 ext 3245
--------------------------------------------+----------------------------------
These ideas and others like them can be had | GEC-Marconi Research is not
for $0.02 each from any reputable idealist. | responsible for my opinions

Re: OOD, Ada, and Inheritance

[John Goodsen]

emery@Dr_No.mitre.org (David Emery) writes:

>
>Finally, you might want to consider 'Classic-Ada', which is a
>pre-processor that takes an "object oriented Ada" and translates it to
>legal Ada.
>

Or better yet, DRAGOON which supports multiple inheritance.
See the FAQ for details.

--
John Goodsen                           PCIS Programme
Software Process & Environments        Ada Joint Program Office       
EVB Software Engineering               goodsenj@ajpo.sei.cmu.edu
jgg@evb.com

Re: OOD, Ada, and Inheritance

[mole-end!mat]

In article <1992Nov5.190921.21374@sei.cmu.edu>, wellerd@ajpo.sei.cmu.edu (David
 Weller) writes:
> In article <mmaccorm.47@fox.nstn.ns.ca> mmaccorm@fox.nstn.ns.ca (Mike Mac Cor
mack) writes:
> >If Ada software is being designed using OOA and OOD, should inheritance be 
> >avoided (or prohibited) in the design process, as Ada does not provide 
> >inheritance? 
 
> ...  the Space Station Verification and Training Facility, is
> applying both OOA and OOD.  It is definitely a non-trivial project, ...
 
> Our inheritance is "manual", ... pass-through calls and composition
> to simulate "real" inheritance.  ...  we intend to quickly
> transition to Ada 9X, ...  In the 30 year life of this project, we
> we felt that [this] would give bigger payoffs than [ignoring inheritance].
 
> It seems silly to sacrifice a design to fit in a current language.
> Especially when you know that language will support those
> "prohibited" features in about 2 years.

I'd think that you'd want to distinguish between inheritance that models
the problem, inheritance that models the solution, and inheritance as
an implementation tool.

Inheritance that models the problem is probably worth staying with, even
at a high present cost and a high risk of subtle differences between your
`simulation' and the actual feature.

Inheritance that models the solution is probably economical only if it
has a very high present value and if it will be flexible enough to be
reimplemented cheaply with whatever version of inheritance is added to
the language.

Inheritance as an implementation tool is probably not worthwhile unless
it confers a very strong and very specific architectural advantage.

(Just my $0.02 worth ...)
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ

Re: OOD, Ada, and Inheritance

[John Goodsen]

>
>I recall that ADA's genericity system allows you to pass functions and
>procedures as parameters in a way reminiscent of the C function
>pointers (although ADA is type-safe).  I would look into the
>possibility of simulating inheritance by setting up structures of
>functions when objects are created.  You should be able to get single
>inheritance without too much trouble.  Maybe an ADA guru can suggest
>some details.
>
>

Look at chapter 9 of "Object-Oriented Reuse, Concurrency and
Distribution - An Ada-Based Approach", by Atkinson - ACM PRESS.

It provides a translation strategy of DRAGOON to Ada.

--
John Goodsen                           PCIS Programme
Software Process & Environments        Ada Joint Program Office       
EVB Software Engineering               goodsenj@ajpo.sei.cmu.edu
jgg@evb.com

Re: OOD, Ada, and Inheritance

[think.com!sdd.hp.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!elephan]

The questions about inheritance in Ada, and especially the responses
about inheritance being "simulated" in Ada, are interesting.  Those
who are REALLY interested in this issue would do well to consider
whether inheritance (as commonly practiced in OO languages) is
something you ought to want; see the paper by J.P. Rosen in the Nov
1992 issue of Comm of the ACM.

Cheers,
    -Bruce

Re: OOD, Ada, and Inheritance

[Jorge Luis Diaz-Herrera]

In article <1992Nov9.145313.18741@cis.ohio-state.edu>, weide@elephant.cis.ohio-
state.edu (Bruce Weide) writes:
|> The questions about inheritance in Ada, and especially the responses
|> about inheritance being "simulated" in Ada, are interesting.  Those
|> who are REALLY interested in this issue would do well to consider
|> whether inheritance (as commonly practiced in OO languages) is
|> something you ought to want; see the paper by J.P. Rosen in the Nov
|> 1992 issue of Comm of the ACM.
|> 
|> Cheers,
|>     -Bruce

Furthermore, look at the following paper:
"Object-oriented Software Reuse: the Yoyo Problem" David Taenzer, et al
Journal of Object-Oriented Programming, Sept./Oct. 1989, pp 30-35.

jld-h
--..--

Re: OOD, Ada, and Inheritance

[eru.mt.luth.se!lunic!sunic!lth.se!newsuser]

In <comp.lang.ada,comp.object> weide@elephant.cis.ohio-state.edu (Bruce Weide) 
writes:
>The questions about inheritance in Ada, and especially the responses
>about inheritance being "simulated" in Ada, are interesting.

Following the argument that inheritance is not essential for OOP
because (1) it is most important in the analysis phase, and (2), it
can be simulated:

There is no need for any module support in the programming language.
The modularization is made during the analysis phase, and procedure
and function names are sufficient to do the subroutine call.

Anyone care to comment?

		-- Dag

Re: OOD, Ada, and Inheritance

[Ralph Johnson]

weide@elephant.cis.ohio-state.edu (Bruce Weide) writes:

>The questions about inheritance in Ada, and especially the responses
>about inheritance being "simulated" in Ada, are interesting.  Those
>who are REALLY interested in this issue would do well to consider
>whether inheritance (as commonly practiced in OO languages) is
>something you ought to want; see the paper by J.P. Rosen in the Nov
>1992 issue of Comm of the ACM.

I have read Rosen's paper several times, and I dislike it more
every time I read it.  The fact that inheritance *can* be misused is 
no argument against it.  Rosen was putting up a straw man -- people 
in the C++ and Smalltalk community place great value in components and
do *not* believe that inheritance is the only, or even the primary,
way to reuse software.  I suppose you could get that opinion from
reading papers, since a lot of papers on software reuse from an OO 
point of view are a bit one-sided and don't give a complete picture,
but you can't get that opinion if you look at the kind of systems
that are built.  For example, the GNU C++ classes rely almost
entirely on reuse by composition.  This is one of its weaknesses,
in my opinion, because the best reusable frameworks will carefully
trade off the extensibility and higher coupling of inheritance with
the ease of use and run-time flexibility of composition, but it
certainly shows that people in the C++ community value composition.
InterViews or the latest version of Model/View/Controller from ParcPlace
ARE very good examples of how to combine inheritance and composition to
make something that is much more powerful and easy to use than either
technique could provide on its own.

Just as serious a problem with Rosen's paper is the opinion that
polymorphism is optional and can be done by hand when needed.  We
could say the same thing about control structures, of course.  In
practice, lack of language support for polymorphism will mean that
people will not use it for little things, and will consider using
it to be difficult and a technique to be used only for hard problems.
In contrast, in C++ or Smalltalk polymorphism is so easy to use that
it is almost bad design to ever use a case statement, and so programs
are easier to extend.  Rosen seemed to contradict himself when he
talked about why Ada 9X wanted to add support for polymorphism, so
perhaps he doesn't really believe this, but was just trying to explain
why Ada was designed the way it was.  Ada is 14 years old, so trying
to justify it in terms of current software engineering practices seems
pointless to me.  (Note: "justify" is not "analyze" or "critique".)

I've been pretty negative about his paper.  The thing I liked about
his paper was his examples of designs that used inheritance
that would probably be better of using composition.  He is right.
There are several different ways of using inheritance, and I suppose
some of the differences are just stylistic, and there might not be
a right or wrong way, but I tend to agree with him that the examples
he gave are bad examples, and that composition is a better way to
solve those problems.  Where I disagree with him is his claim that
the entire object-oriented community, or even the majority of it,
thinks that these examples are good design.  Moreover, I disagree
that his examples showed what is important about inheritance.

After 7 years of experience in building object-oriented systems, I
think that polymorphic composition probably has a bigger impact on 
program structure than inheritance, but I wouldn't want to give up 
inheritance.  Some important design patterns that are based on inheritance 
are template methods in abstract classes (which can be simulated by 
generics in Ada), default implementation of abstract methods or overriding 
standard templates for greater efficiency (which can't be), and use of 
abstract classes to represent behavioral constraints on interfaces.  I 
want to have inheritance in my programming languages.  I am perfectly 
happy for someone to improve it or come up with new ways of doing the 
same things, but standard composition is not a replacement for inheritance, 
but is instead an addition.  (Or inheritance is an addition to composition,
since composition was first.)

Ralph Johnson -- University of Illinois at Urbana-Champaign

Re: OOD, Ada, and Inheritance

[sun-barr!cs.utexas.edu!natinst.com!news.dell.com!milano!cobweb.mcc.com!br]

In article <BxGpxt.FDw@cs.uiuc.edu> johnson@cs.uiuc.edu (Ralph Johnson) writes:
>
>Just as serious a problem with Rosen's paper is the opinion that
>polymorphism is optional and can be done by hand when needed.  ...
>                           ...
>...  Rosen seemed to contradict himself when he
>talked about why Ada 9X wanted to add support for polymorphism, so
>perhaps he doesn't really believe this, but was just trying to explain
>why Ada was designed the way it was.  ...

I saw no contradiction in Rosen's presentation of Ada 9X run-time
polymorphism.  Rather, it appeared to me he stressed the flexibility
of Ada 9X to allow *either* explicitly coded compile-time polymorphism
*or* dynamic binding through tagged types.  Either mechanism may apply,
at the whim of the initial designer.  See "Ada 9X: A Technical Summary"
by S. Tucker Taft, also in Comms. of the ACM Nov92, for a detailed
example of both paradigms.

>After 7 years of experience in building object-oriented systems, I
>think that polymorphic composition probably has a bigger impact on 
>program structure than inheritance, but I wouldn't want to give up 
>inheritance.

I enter this arena attempting to reconcile 12 years of experience designing
and developing Ada/C/assembly software with a mixture of the good parts
of different structured/top down/bottom up methodologies.  My background
focuses tightly on application construction with little consideration
of methodology theory aside from what it can do for me as a tool.
Object-oriented design initially struck me as analogous to an old dance
partner wearing new threads.  New jargon for "commonly" accepted required
architecting tasks did not necessarily impress me.  Now don't light those
flame throwers just yet...I just felt like I'd been using OO techniques
years before they were invented.

Given real constraints for building a product and budgetary limits for
maintaining controllable life cycle costs, I want a method and
accompanying toolset that holds its value and usefulness throughout
the life of the product.  The method/tool cannot be an end, in and of itself.
Instead, it must *support* production without forcing designers to twist
the design to fit the method paradigm or to spend inordinate amounts of time
servicing the tool (to the detriment of iterating the design).

With this in mind, although I find much of Rosen's logic sound, I disagree
with his assertion that composition and classification are not reconcilable.
What we have in common practice is an amorphous blend of the two.  I assert
that successful designers employ aspects of structured and object oriented
methodology to get the job done (do not read "hack" into this).  "Implosive"
analysis and design marries the results of each successive level of
SA/SD and OOA/OOD to define requirements/problem domain, to allocate
functionality/abstraction layers, and to determine composition/inheritance
reuse of components.

SA/SD is not inherently deficient, OOA/OOD is not the unique "second coming",
inheritance is not better than composition (or vice versa), and real world
developments cannot rely entirely on a single methodology (as now defined)
to assure their success.  Just as no single program can solve all problems,
no single methodology addresses all development domains.  In practicality,
we really need a "fuzzy" methodology that taps into the strengths of all.

>want to have inheritance in my programming languages.  I am perfectly 
>happy for someone to improve it or come up with new ways of doing the 
>same things, but standard composition is not a replacement for inheritance, 
>but is instead an addition.  (Or inheritance is an addition to composition,
>since composition was first.)

Thank you for stating the above...that's the first time I have heard a
staunch OO persona give credit to the evolution of object-oriented
methods, rather than describe it as a radically new invention.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Mark A. Breland             |    Microelectronics and Computer
  Project Leader - AFT        |    Technology Corporation 
  (512) 338-3509              |    3500 West Balcones Drive
  breland@mcc.com             |    Austin, Texas 78759-6509
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Mark A. Breland
breland@mcc.com  "...speaking only for myself, no others and vice versa etc..."

Re: OOD, Ada, and Inheritance

[sun-barr!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!darwin.sura.net!]

In article <1992Nov10.205810.5516@mcc.com> 
 breland@cobweb.mcc.com (Mark Breland) writes:

>In article <BxGpxt.FDw@cs.uiuc.edu> johnson@cs.uiuc.edu (Ralph Johnson) writes
:
>>
>>Just as serious a problem with Rosen's paper is the opinion that
>>polymorphism is optional and can be done by hand when needed.  ...
>>                           ...
>>...  Rosen seemed to contradict himself when he
>>talked about why Ada 9X wanted to add support for polymorphism, so
>>perhaps he doesn't really believe this, but was just trying to explain
>>why Ada was designed the way it was.  ...
>
>I saw no contradiction in Rosen's presentation of Ada 9X run-time
>polymorphism.  Rather, it appeared to me he stressed the flexibility
>of Ada 9X to allow *either* explicitly coded compile-time polymorphism
>*or* dynamic binding through tagged types.  Either mechanism may apply,
>at the whim of the initial designer.  See "Ada 9X: A Technical Summary"
>by S. Tucker Taft, also in Comms. of the ACM Nov92, for a detailed
>example of both paradigms.

Speaking for myself ;-), J. P. Rosen's views are somewhat different
from those of the Ada 9X Mapping/Revision Team.  We do believe
that inheritance with type extension and run-time polymorphism are
important additional capabilities, and in fact are more type safe
than the typical equivalent code based on variant records and
case statements.  And of course, the dynamic binding inherent
in run-time polymorphism opens up whole new ways of partitioning
a system into independent subsystems while still retaining type safety.
Since reusable and relatively independent subsystems are critical
to the productive construction of large systems, dynamic binding (run-time
polymorphism) is itself critical to this process.

And since most type-safe dynamic binding is based on the commonality
ensured through the rules of inheritance (at least of interface), 
the two are inseparable in most OOPLs.

>>. . . (Or inheritance is an addition to composition,
>>since composition was first.)
>
>Thank you for stating the above...that's the first time I have heard a
>staunch OO persona give credit to the evolution of object-oriented
>methods, rather than describe it as a radically new invention.

We also believe that object-oriented approaches are a natural
outgrowth of earlier work, in particular abstract-data-type (ADT)-oriented 
approaches.  The big thing that OO brings is robust support
for abstractions with *multiple* implementations.  Although the
concept of multiple implementations of a given abstract data type
was always discussed in academic circles, pre-OO languages with
abstract data types rarely had good support for multiple implementations.

Inheritance and run-time polymorphism make multiple implementations
for a given abstraction practical and workable, allowing code
to be written that works on any derivative of a given type just
as well as it works on the original "root" type of the hierarchy.
The "trick" is that each object carries enough information to identify
its own particular implementation, allowing automatic run-time dispatch
to the "appropriate" implementation of any given "primitive" operation
of the abstraction.  The only thing needed to ensure type safety
is that the operation exists with the given parameter profile;
the actual implementation of the operation need not be known (nor even
exist) at compile-time of the client of the operation.

In other words, the big step from "type-oriented" to "object-oriented"
is not the concept of abstraction, but rather the concept that an
object identifies its own implementation; its compile-time-known
type only identifies its interface.

>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  Mark A. Breland             |    Microelectronics and Computer
>  Project Leader - AFT        |    Technology Corporation 
>  (512) 338-3509              |    3500 West Balcones Drive
>  breland@mcc.com             |    Austin, Texas 78759-6509
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

S. Tucker Taft     stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138

Re: OOD, Ada, and Inheritance

[Bruce Weide]

In article <1992Nov11.042043.9740@inmet.camb.inmet.com>
stt@spock.camb.inmet.com (Tucker Taft) writes:
>
>We also believe that object-oriented approaches are a natural
>outgrowth of earlier work, in particular abstract-data-type (ADT)-oriented 
>approaches.  The big thing that OO brings is robust support
>for abstractions with *multiple* implementations.  Although the
>concept of multiple implementations of a given abstract data type
>was always discussed in academic circles, pre-OO languages with
>abstract data types rarely had good support for multiple implementations.
>

Good point about multiple implementations, but you don't need OO
mechanisms like inheritance to get multiple implementations.  For
example, the idea of multiple implementations is a central feature of
RESOLVE, which has no OO features except a special kind of
specification inheritance that has no bearing on multiple
implementations.  In fact, it seems Ada could be extended with (direct
language support for) multiple implementations, e.g., by permitting
separate naming of package specs and bodies and a way of binding them
together at instantiation time.  See a paper by M. Sitaraman in Proc.
ICCL, Apr 1992, for some ideas on how this could be done.  Ada-9X
doesn't seem to use this approach as I understand it.  Is there a
problem because of some subtle Ada eccentricity that I'm not seeing?

Or, by multiple implementations, do you mean to insist on run-time
selection among different implementations?  If so, what examples would
you (e.g., Ralph, or others holding this view) consider to be "good"
examples of the use of inheritance for this purpose; to be contrasted
with Rosen's examples, which are criticized as unrepresentative of
good OO practices?

>The only thing needed to ensure type safety
>is that the operation exists with the given parameter profile;
>the actual implementation of the operation need not be known (nor even
>exist) at compile-time of the client of the operation.
>
>In other words, the big step from "type-oriented" to "object-oriented"
>is not the concept of abstraction, but rather the concept that an
>object identifies its own implementation; its compile-time-known
>type only identifies its interface.

I'm sure I'm not telling anyone reading this anything they don't
already know, but there's more to the interface than the parameter
profile.  If you want to reason about how a client program is going to
behave when you call some operation, you'd better have some
implementation-independent specification of the abstract behavior of
that operation.  Put another way, correct software involves a lot more
than type-safety.  ALL the different implementations that might
actually be invoked by a call must have the same abstract behavior, or
you're going to have a hell of a time writing correct software (or at
least convincing yourself that it is correct).

What abstract explanation of this behavior are you going to use, then?
We could argue that this is not a language issue (at least not for an
implementation language like Ada), but someone has to think about this
problem before we can conclude which uses of inheritance are "good"
and which are "bad" from a software engineering perspective.


Cheers,
    -Bruce

Re: OOD, Ada, and Inheritance

[klamath.cs.washington.edu!chambers]

In article <1992Nov13.203723.26049@cis.ohio-state.edu>, weide@elephant.cis.ohio
-state.edu (Bruce Weide) writes:
|> ...
|> Or, by multiple implementations, do you mean to insist on run-time
|> selection among different implementations?  If so, what examples would
|> you (e.g., Ralph, or others holding this view) consider to be "good"
|> examples of the use of inheritance for this purpose; to be contrasted
|> with Rosen's examples, which are criticized as unrepresentative of
|> good OO practices?

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.

I see the other side as part of teaching an undergrad compilers
course.  The compiler substrate that the students extend is written in
Ada, and the tagged variants, enums, and case statements that litter
the code are awful.  Adding a few new language constructs would be
simple in an OO implementation but is difficult in this "standard"
implementation.

-- Craig Chambers

Re: OOD, Ada, and Inheritance

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!Sirius.dfn.d]

dag@control.lth.se (Dag Bruck) writes:

>In <comp.lang.ada,comp.object> weide@elephant.cis.ohio-state.edu (Bruce Weide)
 writes:
>>The questions about inheritance in Ada, and especially the responses
>>about inheritance being "simulated" in Ada, are interesting.

>Following the argument that inheritance is not essential for OOP
>because (1) it is most important in the analysis phase, and (2), it
>can be simulated:

>There is no need for any module support in the programming language.
>The modularization is made during the analysis phase, and procedure
>and function names are sufficient to do the subroutine call.

>Anyone care to comment?

Yes: And, since it can be simulated all in Assembler, there is no need for
new programming languages at all ;>).

>		-- Dag

Ok, let's get serious. People develop new programming language concepts to
free their task from ever the same details. Therefore, we have procedures
and so on, and do not need to simulate this concept (would you?). But, if
you do not trust them, don't use them. It's the same with inheritance.
Inheritance is an important concept in analysis and design (mostly used for
subtyping purposes). A lot of people use it successfully in programming, and
are satisfied with this concept. And the situation is (more as) the same for
module concepts. If you don`t want to use them, don't do it.

There is also no need for cars. And, of course there are lots of
contraindicators for using cars. And, there are lots of ways simulating the
task "going from A to B" (walking, running, by bike, by train, ...).

-- jubo
****************************************************************************
* Ju"rgen Bo"rstler             * e-mail:                                  *
* RWTH Aachen                   *    jubo@rwthi3.informatik.rwth-aachen.de *
* Lehrstuhl fuer Informatik III *                                          *
* Ahornstrasse 55               *                                          *
* W-5100 Aachen                 * phone: +49/ 241/ 80-21310                *
* Germany                       * fax:               -21329                *
****************************************************************************

--
****************************************************************************
* Ju"rgen Bo"rstler             * e-mail:                                  *
* RWTH Aachen                   *    jubo@rwthi3.informatik.rwth-aachen.de *
* Lehrstuhl fuer Informatik III *                                          *

Re: OOD, Ada, and Inheritance

[eru.mt.luth.se!lunic!sunic!mcsun!uknet!comlab.ox.ac.uk!ajs]

In article <1992Nov13.203723.26049@cis.ohio-state.edu> weide@elephant.cis.ohio-
state.edu (Bruce Weide) writes:
>In article <1992Nov11.042043.9740@inmet.camb.inmet.com>
>stt@spock.camb.inmet.com (Tucker Taft) writes:
>>
>>We also believe that object-oriented approaches are a natural
>>outgrowth of earlier work, in particular abstract-data-type (ADT)-oriented 
>>approaches.  The big thing that OO brings is robust support
>>for abstractions with *multiple* implementations.  Although the
>>concept of multiple implementations of a given abstract data type
>>was always discussed in academic circles, pre-OO languages with
>>abstract data types rarely had good support for multiple implementations.
>>
>
>Good point about multiple implementations, but you don't need OO
>mechanisms like inheritance to get multiple implementations.  For
>example, the idea of multiple implementations is a central feature of
>RESOLVE, which has no OO features except a special kind of
>specification inheritance that has no bearing on multiple
>implementations.  In fact, it seems Ada could be extended with (direct
>language support for) multiple implementations, e.g., by permitting
>separate naming of package specs and bodies and a way of binding them
>together at instantiation time.  See a paper by M. Sitaraman in Proc.
>ICCL, Apr 1992, for some ideas on how this could be done.  

This work is much more older, dating back to the specification language Clear
and more recently to the language LIL. See

  @ARTICLE{Goguen:computer86,
    AUTHOR  = "Goguen, Joseph",
    TITLE   = "Reusing and Interconnecting Software Components",
    JOURNAL = "Computer",
    MONTH   = "February",
    YEAR    = 1986,
    VOLUME  = 19,
    NUMBER  = 2,
    PAGES   = "16-28"}

Cheers,
Adolfo

Re: OOD, Ada, and Inheritance

[dog.ee.lbl.gov!pasteur!agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.ed]

In article <1992Nov16.150904.6822@ruby.comlab.ox.ac.uk>
Adolfo.Socorro@prg.oxford.ac.uk (Adolfo Socorro) writes (quoting me):

>>...  In fact, it seems Ada could be extended with (direct
>>language support for) multiple implementations, e.g., by permitting
>>separate naming of package specs and bodies and a way of binding them
>>together at instantiation time.  See a paper by M. Sitaraman in Proc.
>>ICCL, Apr 1992, for some ideas on how this could be done.  
>
>This work is much more older, dating back to the specification language Clear
>and more recently to the language LIL. See
>
>  @ARTICLE{Goguen:computer86,
>    AUTHOR  = "Goguen, Joseph",
>    TITLE   = "Reusing and Interconnecting Software Components",
>    JOURNAL = "Computer",
>    MONTH   = "February",
>    YEAR    = 1986,
>    VOLUME  = 19,
>    NUMBER  = 2,
>    PAGES   = "16-28"}
>

Just to clarify, I wasn't contending that the paper I mentioned
contains the first reference to multiple implementations!  Of course
this is not a new idea.  What that paper contains, however, is a
specific proposal for how to include support for multiple
implementations in Ada, with fairly minor changes.
    -Bruce

Re: OOD, Ada, and Inheritance

[klamath.cs.washington.edu!chambers]

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

Re: OOD, Ada, and Inheritance

[pipex!bnr.co.uk!bnrgate!nott!cunews!cunews!knight]

In <1992Nov30.230312.8279@cis.ohio-state.edu> weide@elephant.cis.ohio-state.edu
 (Bruce Weide) writes:

>In article <1992Nov26.012530.7587@fcom.cc.utah.edu>
>val@news.ccutah.edu (Val Kartchner) writes of an example where
>polymorphism is useful.  But unfortunately this example does not
>address the question I was asking, especially the part underlined
>below.  At great risk I therefore repeat the challenge, which was
>prompted originally by some complaints about the quality of the
>examples in J. Rosen's paper that recently appeared in CACM:

>>: 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.

1) I/O 
The ability to write to files, pipes, the screen, etc. interchangeably
at run-time is extremely useful, and practically everybody does it
this way.

2) Matrix libraries 

There are a number of different representations of matrices
(sparse,dense,symmetric,asymmetric,definite,upper triangular, real,
double, complex). These differ very significantly in representation
and in the implementation of operations on them, but they all follow
the same abstract behaviour of a matrix. It is clearly nice to be able
to write code that operates on any matrix, and which will use the
appropriate algorithm.

In fact, now that I think about it, numbers themselves are another
example. Reals and doubles have identical abstract behaviour, and
complex numbers add only a few additional functions while leaving the
others unchanged. They clearly have different representations and
operations must take this into account.

3) Finite element types 

I work in finite element analysis, in which we have a number of
different "element types", which can vary with the geometry of the
element or with its properties. Examples would be the 8-node brick,
4-node tetrahedron, 27-node brick, etc.

Without going into too much detail, the routines for solving finite
element problems expect the same abstract behaviour from these
elements (that they give the right answer) without regard to the
internal structure of the elements.
I can elaborate on this if anybody is interested. 


I hope these are the sort of examples you are looking for. 

-- 
 Alan Knight  knight@mrco.carleton.ca  +1 613 788 2600x5783 
 Dept. of Mechanical and Aerospace Engineering              
 Carleton University, Ottawa, Ontario, Canada, K1S 5B6      

Re: OOD, Ada, and Inheritance

[dog.ee.lbl.gov!network.ucsd.edu!usc!zaphod.mps.ohio-state.edu!cis.ohio-st]

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

Re: OOD, Ada, and Inheritance

[dog.ee.lbl.gov!overload.lbl.gov!agate!usenet.ins.cwru.edu!magnus.acs.ohio]

In <1992Dec2.202522.2335@cis.ohio-state.edu> weide@elephant.cis.ohio-state.edu 
(Bruce Weide) writes:

>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.

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.

Another common OO example is a tree class in which leaves and internal
nodes are implemented in different ways. In this case the leaves may
behave quite differently from the others in detail, but one would
still consider them to be the same in the abstract. The same applies
to a linked-list implementation with an end-of-list that is of a
separate class rather than just being null.

-- 
 Alan Knight  knight@mrco.carleton.ca  +1 613 788 2600x5783 
 Dept. of Mechanical and Aerospace Engineering              
 Carleton University, Ottawa, Ontario, Canada, K1S 5B6      

Re: OOD, Ada, and Inheritance

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!paladin.amer]

>>>>: 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.

I'm not sure what is meant by `similar but not identical' in this
context, so I'll talk a little more generally.

The classic example is of course the graphic drawing library, where all
the drawable classes must have common behaviour such as being
drawable, rotatable, expandable, stretchable etc, but some classes
have additional behaviour, such as a drawable text class which also
has features that allow the text to be altered.  In this case the
drawable features for the various classes are similar (they draw the
shapes) but not identical (each shape is different).

Or if you want the same logical behaviour with different
implementations, consider the single and double linked list.  A
developer may not know when coding starts which implementation to
choose.  If both single and double linked lists share a common
interface then the developer can pick one safe in the knowledge that
switching to the other is a trivial change.

If your data structure library has tables of objects and lists of
objects then you could also have a class which inherits from both
table and list.  This allows you to pass this to a routine that expects a
list and to one that expects a table.

It is important to remember that inheritance is not about reusing the
implementation of your class (you can do that by delegation).  It is
about reusing the *interface*, because that way you get to reuse all
the other code out there that uses the interface.

Paul.

-- 
Paul Johnson (paj@gec-mrc.co.uk).	    | Tel: +44 245 73331 ext 3245
--------------------------------------------+----------------------------------
These ideas and others like them can be had | GEC-Marconi Research is not
for $0.02 each from any reputable idealist. | responsible for my opinions

Re: OOD, Ada, and Inheritance

[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