Internet Info 1993/Internet Info CD-ROM (Walnut Creek) (1993).iso/answers/comp/object-faq/part2

Text File | 1993-12-15 | 58.4 KB | 1,325 lines

Newsgroups: comp.object,comp.answers,news.answers
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!nic.hookup.net!europa.eng.gtefsd.com!howland.reston.ans.net!vixen.cso.uiuc.edu!uchinews!news
From: Bob Hathaway <[e-mail]>
Subject: Comp.Object FAQ Version 1.0.5 (12-13) Part 2/8
Message-ID: <[e-mail]>
Followup-To: comp.object
Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
Sender: [e-mail] (News System)
Organization: Geodesic Systems
Date: Tue, 14 Dec 1993 04:43:09 GMT
Approved: [e-mail]
Lines: 1310
Xref: senator-bedfellow.mit.edu comp.object:13849 comp.answers:2990 news.answers:15748

Archive-name: object-faq/part2
Last-Modified: 12/13/93
Version: 1.0.5

"Poly" means "many" and "morph" means "form".  The homograph polymorphism has
many uses in the sciences, all referring to objects that can take on or assume
many different forms.  Computer Science refers to Strachey's original
definitions of polymorphism, as divided into two major forms, parametric and
ad-hoc.  Cardelli and Wegner followup with another classification scheme,
adding inclusion polymorphism for subtyping and inheritance.


> Strachey's Original Definition [Strachey 67]:

"Parametric polymorphism is obtained when a function works uniformly on a range
of types; these types normally exhibit some common structure.  Ad-hoc
polymorphism is obtained when a function works, or appears to work, on several
different types (which may not exhibit a common structure) and may behave in
unrelated ways for each type."

Parametric polymorphism is also referred to as "true" polymorphism, whereas
ad-hoc polymorphism isn't (apparent polymorphism).


> Cardelli and Wegner's Definition [Cardelli 85]:

C+W refine Strachey's definition by adding "inclusion polymorphism" to model
subtypes and subclasses (inheritance).  Strachey's parametric polymorphism is
divided into parametric and inclusion polymorphism, which are closely related,
but separated to draw a clear distinction between the two forms, which are then
joined as specializations of the new "Universal" polymorphism.

                                 |-- parametric
                 |-- universal --|
                 |               |-- inclusion
  polymorphism --|
                 |               |-- overloading
                 |-- ad hoc    --|
                                 |-- coercion

Polymorphic Languages: some values and variables may have more than one type.

Polymorphic Functions: functions whose operands (actual parameters) can
  have more than one type.  [...] If we consider a generic function to be
  a value, it has many functional types and is therefore polymorphic.

Polymorphic Types: types whose operations are applicable to operands of more
  than one type.

Parametric Polymorphism: a polymorphic function has an implicit or explicit
  type parameter which determines the type of the argument for each
  application of that function.

Inclusion Polymorphism: an object can be viewed as belonging to many different
  classes that need not be disjoint; that is, there may be inclusion of
  classes.

The two forms of "Universal Polymorphism", parametric and inclusion are closely
related, but are distinct enough in implementation to justify separate
classifications.

Parametric polymorphism is referred to as generics.  Generics can be syntactic,
where each instantiation creates a specialized version of the code allowing
fast running execution, but in a "true polymorphic system", only a single
implementation is used.

On inheritance is subtype polymorphism:
"Subtyping on record types corresponds to the concept of inheritance
(subclass) in languages, especially if records are allowed to have functional
components."

Author's Notes:
Implicit parametric polymorphism can be implemented with type inferencing
schemes [Aho 85].  ML is prototypical in providing this facility.

Inclusion polymorphism is common and is found in languages such as Simula,
Ada-9x, C++, CLOS, Eiffel and etc. (subclass polymorphism).  Smalltalk also
uses inclusion polymorphism; its used in declaring classes, and subclass
polymorphism is used in practice but not enforced.  For inheritance, inclusion
polymorphism specifies an instance of a subclass can appear wherever an
instance of a superclass is required.  For subtyping (subtype polymorphism),
the same applies because all operations required by the supertype are present
in the subtype (subtype is subset of supertype).  Cardelli and Wegner view
classes as sets of objects (resulting in subtype objects are a subset of
supertype objects, or an extentional view), as contrasted with a feature based
(intentional) approach (where subtypes are supersets of (contain) supertypes).
MI provides an interesting example here, as it is set intersection with an
extensional view and set union with an intentional view.  Details are left as
an exercise for the reader.

Ada generics and C++ templates provide explicit syntactic generics.  While
Ada may infer some actual generic parameters (operations) and C++ doesn't
require explicit instantiation of its template functions, formal generic
parameters must still be declared and many bodies are generated.

Inclusion polymorphism can refer to subtyping, or having at least as much or
more than required.  Since derived classes can inherit structure and behavior
from base classes, such inheritance is an example of inclusion polymorphism
with respect to representation (subclassing).  An example of inclusion
polymorphism with respect to assignment (and initialization, or replacement if
viewed in an almost symbolic way) occurs when object types may be specified and
assignment is based on actual object membership in that type (often of the CLOS
is-a-member-of form in OO).  Emerald provides another example of an object-
oriented language using inclusion polymorphism with respect to replacement;
however, inclusion is with respect to subtyping only with abstract types
("bounded quantification" by C+W.  C+W's parameters are subtype polymorphic
but lose the inherent type).  Any object possessing all required operations is
acceptable and no inheritance relation is required (subtype polymorphism).
They refer to this as "best-fitting" types [Black 86].  The original Trellis/
Owl also had such a facility but with two separate inheritance hierarchies,
although it was abandoned in favor of a single class-based approach for
simplicity.  See also section 2.7.

[As inclusion polymorphism covers both subtype and subclass polymorphism,
 perhaps IP could be further divided in C+W's above classification.]


> Booch's Definition [Booch 91, p. 517]:

polymorphism  A concept in type theory, according to which a name (such as a
variable declaration) may denote objects of many different classes that are
related by some common superclass; thus, any object denoted by this name is
able to respond to some common set of operations in different ways.

Booch also has several sections devoted to polymorphism.

[The author notes Booch's definition above is clearly in the context of
 conventional, classical OO and subclass polymorphism.]


> Meyer's Definition [Meyer 88, sect. 10.1.5 Polymorphism]:

"Polymorphism" means the ability to take several forms.  In object-oriented
programming, this refers to the ability of an entity to refer at run-time to
instances of various classes.  In a typed environment such as Eiffel, this is
constrained by inheritance: ...

[The Author notes Meyer has a following section 10.1.7 on Static Type,
 dynamic type, which is relevant, but claims "... there is no way the type
 of an object can ever change.  Only a reference can be polymorphic: ...".
 Meyer is clear between the concept and the Eiffel realization in his
 polymorphism definition above, but here neglects the "becomes" facility
 as found in several dynamically typed OO languages such as Actors, CLOS,
 Self and Smalltalk, which allows an object (and not just a reference) to
 change its class.]


> Stroustrup's Definition [Stroustrup 90, p. 209]:

The use of derived classes and virtual functions is often called "object-
oriented programming".  Furthermore, the ability to call a variety of
functions using exactly the same interface - as is provided by virtual
functions - is sometimes called "polymorphism".

[The Author notes this is a functional view of polymorphism (as provided in
C++).  [Stroustrup 91, p. 136] has an example of polymorphism with void *'s,
but a newer template function is incomparably preferable, as implied in
[Stroustrup 90, ch 14]]


Rumbaugh's Definition [Rumbaugh 91, p. 2]:

"Polymorphism" means that the same operation may behave differently on
different classes.


2.2)  What Does Polymorphism Boil Down To In OO Programming Languages?
----------------------------------------------------------------------

In C++, virtual functions provide polymorphism.  This is because a polymorphic
object (pointer or reference (or such parameter)) is assignment compatible with
any object of a derived class.  Is this polymorphism in itself?  Objects
can take on objects of different forms (the derived classes), but of what use
is it?  To make any difference, the differing forms must have some effect.  In
dynamically typed languages, polymorphic objects are passed messages and will
respond in whatever way the object has defined (usually starting from its most
derived class and working its way up).  But for static objects, a virtual
function is invoked.  This is the stored method from the derived class that
overrode the virtual method from its base class, providing specialized behavior
for the polymorphic object; and hence, polymorphism.  This common pure
statically typed example is, of course, an example of inclusion polymorphism,
subclass polymorphism to be more specific (see section 2.1).  Pure statically
typed subtype polymorphism, as provided in Emerald, can be implemented
similarly [Black 86].


2.3)  What Is Dynamic Binding?
------------------------------

Dynamic binding has two forms, static and dynamic.  Statically-typed dynamic
binding is found in languages such as C++ (virtual functions) and Eiffel
(redefinition).  It is not known which function will be called for a virtual
function at run-time because a derived class may override the function, in
which case the overriding function must be called.  Statically determining all
possibilities of usage is undecidable.  When the complete program is compiled,
all such functions are resolved (statically) for actual objects. Formal object
usage must have a consistent way of accessing these functions, as achieved thru
vtables of function pointers in the actual objects (C++) or equivalent,
providing statically-typed dynamic binding (this is really just defining simple
function pointers with static typechecking in the base class, and filling them
in in the derived class, along with offsets to reset the receiver).

The run-time selection of methods is another case of dynamic binding, meaning
lookup is performed (bound) at run-time (dynamically).  This is often desired
and even required in many applications including databases, distributed
programming and user interaction (e.g. GUIs).  Examples can be found in
[Garfinkel 93, p80] and [Cox 91, pp 64-67].  To extend Garfinkels example with
multiple-polymorphism, a cut operation in an Edit submenu may pass the cut
operation (along with parameters) to any object on the desktop, each of which
handles the message in its own way (OO).  If an (application) object can cut
many kinds of objects such as text and graphical objects, multiple-polymorphism
comes into play, as many overloaded cut methods, one per type of object to be
cut, are available in the receiving object, the particular method being
selected based on the actual type of object being cut (which in the GUI case is
not available until run-time).

Again, various optimizations exist for dynamic lookup to increase efficiency
(such as found in [Agrawal 91] and [Chambers 92]).

Dynamic binding allows new objects and code to be interfaced with or added to
a system without affecting existing code and eliminates switch statements.
This removes the spread of knowledge of specific classes throughout a system,
as each object knows what operation to support.  It also allows a reduction in
program complexity by replacing a nested construct (switch statement) with a
simple call.  It also allows small packages of behavior, improving coherence
and loose coupling.  Another benefit is that code complexity increases not
linearly but exponentially with lines of code, so that packaging code into
methods reduces program complexity considerably, even further that removing
the nested switch statement!  [Martin 92] covers some of these issues.


2.4)  Is There A Difference Between Being A Member Or Instance Of A Class?
--------------------------------------------------------------------------

Yes (but be careful of context).  To use C++ terminology, an object (not
a reference) is defined to be an instance of exactly one class (in classical
OO), called its most derived class.  An object not directly contained in any
other is called the complete object [Stroustrup 90].  An object is a member
of several classes, including all of the classes its declared (or most derived)
class inherits from.  With static typing and inclusion polymorphism based on
class, if a polymorphic object (or reference) is made to refer to an object,
that object must be a member of the polymorphic object's class.

This also provides a good example of differing definitions among object-
oriented languages, since a member is defined as above in CLOS, but a member of
a class is one of its instance variables in C++.


2.5)  What Is The Difference Between Static And Dynamic Typing?
---------------------------------------------------------------

Static typing refers to types declared in a program at compile-time, so no type
information is available on objects at run-time.  Dynamic typing uses the
inherent types of polymorphic objects, keeping track of the types of objects at
run-time.  Statically typed dynamic binding is a compromise (usually
implemented with tables of function pointers and offsets), and is how
statically-typed OO languages provide polymorphism.  Some approaches provide
both static and dynamic typing, sometimes with static typing providing type-
safe programs and dynamic typing providing multiple-polymorphism [Agrawal 91]
[Mugridge 91].  See also section 2.3.

Static typing is more efficient and reliable, but loses power.  Typical
restrictions include only allowing a common set of base class functions (or
any common functions for the more general subtyping or parametric polymorphic
cases) to be available on formal objects and a lack of multiple-polymorphism
(see section 1.19), both of which are overcome with dynamic typing.

Many languages provide dynamic typing: Smalltalk, Self, Objective-C, and etc.
A limited dynamic typing scheme, called RTTI (Run Time Type Identification),
is even being considered for the C++ standard.  A similar facility to safe
downcasting (historically known as type narrowing), the thrust of RTTI, can
also be found in recent versions of Eiffel.

See section 3.4 for a categorization of common OO languages by type system.


2.6)  What Is This I Hear About ML And Functional Programming Languages?
------------------------------------------------------------------------

ML, Metalanguage, is a functional programming language with a strongly typed
polymorphic type system [Wikstrom 87].  Russell (see Appendix E) is a more
recent functional language and Haskell [Hudak 92] provides a more modern and
"pure" example.  Section 2.5 discusses why static typing has less power/
flexibility than dynamic typing and the same applies to ML (although see the
appendixes for an experimental dynamic extension to ML, Alcool-90 and [Cardelli
85] for a proper placement of ML's type system).  ML doesn't use inheritance
for polymorphism; unlike OO languages, but provides the prototypical example of
parametric polymorphism, so no inheritance is required.  This is "true" or
"pure" statically (or strongly) checked parametric polymorphism, by Strachey's
(and Cardelli and Wegner's) definitions.

Smalltalk is an example of a dynamically-typed language which does not check
types during assignment (and hence for parameters) and therefore provides
parametric polymorphism without static constraints (by Strachey's definition).
However, Smalltalk's style uses inclusion polymorphism in practise and
inheritance for subclassing (representation).


2.7)  What Is A Separation Between Type And Class (Representation)?
-------------------------------------------------------------------

For a short answer:
  Subtype Polymorphism, as opposed to Subclass Polymorphism, is the best answer
  in OO.  Parametric polymorphism is a related concept where this is also true,
  but is of a different flavor (and usually requires object attributes by use.
  See also section 2.1).

A type can be considered a set of values and a set of operations on those
values.  This can insure type-safe programming.  However, the representation of
types (classes in OO) can be separated from the notion of type allowing many
representations per type while still maintaining reasonable type-safety.

In many languages, a type has a single representation insuring all operations
performed on that type are well defined (statically bound) and providing for
efficiency by taking advantage of that representation wherever used.  In many
OO languages, subclassing and dynamic binding provides for greater flexibility
by providing object specialization.  However, in many OO languages classes are
used for assignment compatibility forcing an assigned object to inherit
(transitively) from any polymorphic object's class (inclusion polymorphism
based on class, or subclass polymorphism).  This insures all operations to be
performed on any polymorphic object are satisfied by any replacing objects.
This also insures all types share a common representation, or at least a
common base interface specification.

By separating type from class, or representation (or perhaps separating class
from type, by the aforementioned definition of type), a replacing object must
satisfy the operations or type constraints of a polymorphic object (subtype
polymorphism) but are not required to do to do so by an inheritance relation
(subclass polymorphism), as is typical in most OOPLs.  Dropping this
restriction is somewhat less type-safe, because accidental matches of method
signatures can occur, calling for greater care in use.  [Black 86] discusses
this issue in Emerald.  The same issue arises in parametric polymorphism
(generics/templates), as any method matching a required signature is accepted,
calling for careful matching of actual and formal generic parameters.  The
difference between static and dynamic binding in OO and dynamic binding and
subtyping seems similar.  A possible loss of semantic integrity/similarity is
contrasted with greater power.

It is possible to specify desired abstract properties of type specifications
with mechanisms similar to Eiffel's pre-, post-, and invariant conditions.
This helps to insure the semantic integrity of replacing objects and their
behavior.  [Liskov 93] provides a recent exposition.

Abstract classes ([Stroustrup 91] and [Meyer 88]) in typing provide a facility
similar to subtype polymorphism; however, ACs require type compatible classes
to inherit from them, providing a subclass polymorphism facility, and ACs can
also specify representation.  Subtyping is therefore most useful to avoid
spreading knowledge of classes throughout a system, which is a high priority
for loosely coupled modules and in distributed programming [Black 87].

The formal type system found in [Cardelli 85], Emerald/Jade [Black 86] and
[Raj 89], original trellis/Owl, an experimental C++ extension (See Appendix E,
Signatures), Sather (Eiffel-based), and an Eiffel superset [Jones 92] are all
examples of OO systems providing subtype polymorphism.  Functional languages
such as ML, Russell, and Haskell provide a separation with pure parametric
polymorphism (as is also commonly found in OO languages in additon to inclusion
polymorphism).


2.8)  What Are Generics And Templates?
--------------------------------------

Short Answer: Parametric Polymorphism (although various implementations
              provide various subsets).

Generics (or Templates in C++) refer to the ability to parameterize types
and functions with types.  This is useful for parameterized classes and
polymorphic functions as found in languages such as Ada, C++, Eiffel, and
etc., although these are "syntactic" or restricted forms [Cardelli 85].
Generics are orthogonal to inheritance, since types (and classes)
may be generically parameterized.  Generics provide for reusability in
programming languages.  An example is a Stack with a generically
parameterized base type.  This allows a single Stack class to provide
many instantiations such as a Stack of ints, a Stack of any fundamental
or user defined type, or even a Stack of Stacks of ...  Another example is
a polymorphic sort function taking a base type with a comparison operator.
The function can be called with any type (containing a comparison operator).
See [Booch 87b] for several examples in Ada and [Stroustrup xx] and [Murray
93] for examples in C++.

While generics have many advantages, typical limitations include a static
nature, which is an advantage for strong typechecking but a potential
disadvantage when causing dynamic compilation (leading to a time/space
efficiency tradeoff), and sources can cause inlining and create source code
dependencies and expand code size (unlike a single-body or "true"
parametrically polymorphic implementation.  Generics can also be viewed as a
special case of type variables.

Functions are typically generic in statically-typed parametrically-polymorphic
languages.  One such popular functional language is ML, in which all functions
are generic.  Russell and Haskel are more modern variants (references are
forthcoming, however see APPENDIX E).


SECTION 3:  GENERAL
===================

  References:   (many more are to come)
    [Coplien 92]    Covers C++, symbolic, exemplar (single-hierarchy), etc.
    [Kim 89]        Covers many OO systems.


3.1)  What Is The "Classical" Object-Oriented Paradigm?
-------------------------------------------------------

This refers to the usual class and object model.  Its any 2+ level system
as described in section 1.4.  See also [Coplien 92].


3.2)  What Is The "Delegation/Prototyping" Object-Oriented Paradigm?
--------------------------------------------------------------------

See [Kim 89, ch 1,3].

This is the 1 Level System as Described under Meta-Classes.  Delegation refers
to the delegating of responsibility and can be applied to inheritance.  When a
derived class does not have a desired attribute, it "delegates" responsibility
to one of its base classes.  In delegation systems, each object has a delegate
list instead of a parent list. Thus, delegation's primary emphasis is
on message passing where an object could delegate responsibility of a message
it couldn't handle to objects that potentially could (its delegates).  Any
object can be added to the delegate list, giving dynamic inheritance (of a
sort).  Typically, delegation and prototyping languages also have "part
inheritance" in which fields and methods can be added and deleted from objects.
This makes for easy "prototyping", which allows for objects to be constructed
piece by piece at run-time, although the term "prototyping" in the context of
delegation languages usually refers to objects serving as prototypes for
object instantiation, or exemplars.

Next's NextStep OS provides delegation as an add-On to Objective-C, providing
an example of delegation in a class-based language [Garfinkel 93].


3.3)  Are There Any Other Object-Oriented Paradigms?
----------------------------------------------------

There are many alternatives in OO.  Emerald/Jade ([Black 86] and [Raj 89])
provides one, where inheritance is replaced with a roughly equivalent form
where reuse occurs at a finer degree of granularity - method and instance
variables - with subtype polymorphism making up the difference.

CLOS [Kim 89, ch 4] has a looser coupling of methods to classes and doesn't
distinguish a receiver, but packages can help make up the difference.

Object Specialization [Sciore 89] is an example of a hybrid approach between
delegation and classical systems, where parent classes have an extra level
of indirection and inheritance hierarchies are specified on a per object/class
basis.


3.4)  What Are The Major Object-Oriented Programming Languages Today?
---------------------------------------------------------------------

Statically-Typed:
  Add 1 To Cobol giving Cobol with Objects.
  Beta
  C++
  Classic-Ada
  Dragoon
  Emerald/Jade
  Object Pascal
  Trellis/Owl

Dynamically-Typed:
  Actors Languages
  Flavors
  Self
  Smalltalk

Both:
  Actor
  Ada-9x
  C++ (With RTTI)
  Cecil
  CLOS
  Eiffel
  Modula-3
  Objective-C
  Sather


3.5)  What Are Object-Oriented Databases And Persistence?
---------------------------------------------------------

See also Appendices B and E and the comp.database.object newsgroup.
Refs to be included in future FAQs.

Object-Oriented Databases are databases that support objects and classes.  They
are different from the more traditional relational databases because they allow
structured subobjects, each object has its own identity, or object-id (as
opposed to a purely value-oriented approach) and because of support for methods
and inheritance.  It is also possible to provide relational operations on an
object-oriented database.  OODBs allow all the benefits of object-orientation,
as well as the ability to have a strong equivalence with object-oriented
programs, an equivalence that would be lost if an alternative were chosen, as
with a purely relational database.

Another way of looking at Object-Oriented Databases is as a persistent object
store with a DBMS.

Persistence is often defined as objects (and their classes in the case of
OODBs) that outlive the programs that create them.  Object lifetimes can be
viewed as a hierarchy, with locals/automatics having the shortest default
lifetime and objects stored indefinitely in an OODB (which are persistent)
having the longest.  Persistent object stores do not support query or
interactive user interface facilities, as found in a fully supported OODBMS.

Appendix B also contains references for relational interfaces to OODBs.


3.6)  What Are Object-Oriented Operating Systems?
-------------------------------------------------

Refs to be included in future FAQs.  See also Appendix E.

Object-Oriented Operating Systems provide resources through objects, sometimes
all the way down to to the machine (OO architectures are found at the bottom).
They are almost always distributed systems (DOS or DPOS), allowing objects to
be passed freely between machines.  They are typically capability-based since
objects, and hence system resources, can only be accessed if a capability to
them is available to programs.

Here are some abstracts taken from several postings to the net.  This list is
by no means exhaustive.

Chorus Micro-kernel (written in C++)
Choices (research OS, University of Illinois, written in C++, supports SVR4)
GEOS    (GeoWorks', written in Object Assembler, OO superset of 8086)
Mach    (CMU, supports BSD 4.3, really message-based)
NachOS  (written in C++, OS teaching/learning OS)
Ouverture Project (ESPRIT funded OMG IDL defines inter-module interfaces)
SOS
Spring      (Sun, written in C++)
PenPoint OS (Go, written in C++)


From: [e-mail] ()

Insight ETHOS: On Object-Orientation in Operating Systems
ISBN 3 72811948 2

This thesis covers the design of an extensible object-oriented
operating systems. The language used was Oberon-2. It includes
a generalization of the Rider/Carrier principle, Object Directories
as well as basic OS issues such as memory, file, tasking management.
It covers extensible objected-oriented programming from hardware up.
It reviews other designs such as Clouds and Choices which where written
It reviews other designs such as Clouds and Choices which where written
on C++. [[ The lack of type-tests in C++ was a problem in other designs.]]
ETHOS was implemented as an operating system for the Ceres computers
at the ETH.


3.7)  What Are The Current Object-Oriented Methodologies?
---------------------------------------------------------

Here is a list of OOSE Methodologies:

  Berard                        [Berard 93]
  BON                           [Nerson 92]
  Booch                         [Booch 94]
  Coad/Yourdon                  [Coad 91]
  Colbert                       [Colbert 89]
  de Champeaux                  [de Champeaux 93]
  Embley                        [Embley 92]
  EVB                           [Jurik 92]
  FUSION                        [Coleman 94]
  HOOD                          [HOOD 89]
  IBM                           [IBM 90,91]
  Jacobson                      [Jacobson 92]
  Martin/Odell                  [Martin 92]
  Reenskaug (OOram, was OORASS) [Reenskaug 91]
  ROOM                          [APPENDIX D, ObjecTime CASE Toolset]
  Rumbaugh et al.               [Rumbaugh 91]
  Shlaer and Mellor             [Shlaer 88 and 92]
  Wasserman                     [Wasserman 90]
  Winter Partners (OSMOSYS)     [Winter Partners]
  Wirfs-Brock et al.            [Wirfs-Brock 90]

Further Ideas And Techniques:
  Meyer                         [Meyer 88]
  Stroustrup                    [Stroustrup 91]

See APPENDIX D for CASE systems supporting these methodologies (several from
the originators themselves).

See also section 1.21 for a discussion on OOA/OOD and etc.

Summaries and comparisons will be provided in future FAQs.  Suggestions for
inclusion of other major or new methodologies should be sent to the FAQ author.

Here are some comparison studies posted to the net:

Arnold, P., Bodoff, S., Coleman, D., Gilchrist, H., Hayes, F., An Evolution of
Five Object Oriented Development Methods, Research report, HP Laboratories,
June 1991

de Champeaux, Dennis and Faure, Penelope. A comparative study of object-
oriented analysis methods. Journal of Object Oriented Programming (JOOP), pp
21-32.  Vol.5, No. 1, 3/4-92

Fichman R.G. & Kemerer C.F.  OO and Conventional Analysis and Design
Methodologies.  Computer, Oct 1992, Vol 25, No. 10, p 22-40

Fichman, Robert and Kemerer, Chris. Object-Oriented and Conventional Analysis
and Design Methods - Comparison and Critique.  IEEE-Comp, Oct, 1992, pp 22-39.
OOA, OOD, conventional analysis, conventional design, DeMarco SA, Yourdon SA,
Bailin OO requirements specification, Coad-Yourdon OOA, Shlaer-Mellor OOA,
Yourdon-Constantine SD, Martin information engineering design, Wasserman OOSD,
Booch OOD, Wirfs-Brock responsibility-driven design.

Hong, S., van den Goor, G., and Brinkkemper, S.  A Comparison of Object-
oriented Analysis and Design Methods. Working paper, Computer Information
Systems Department, Georgia State University, Atlanta USA, 1992, 12 pages. To
appear in the Proceedings of the 26th Hawaiian international conference on
System Sciences, IEEE Computer Science Press.

Hong, S., van den Goor, G., Brinkkemper, S. A Formal Approach to the Comparison
of Object-Oriented Analysis and Design Methodologies, Hawaii International
Conference on System Sciences (HICSS) (IEEE Computer Society Press, Hawaii)
1993, Vol. IV, pp. 689-698.  Summary of [van den Goor et.al., 1992] below.

  Order procedure:
  Available from the authors at [e-mail] or [e-mail].
  The authors, regretfully, cannot supply ftp, postscript, TEX, or
  whatsoever.

Monarchi, David and Puhr, Gretchen I. A Research Typology for Object-Oriented
Analysis and Design.  CACM/September 1992/Vol.35, No.9, pp35.

[Wilkie 93] summarizes, compares, and provides examples of Booch, Wirfs-Brock,
Hood, Coad and Yourdon, Winter Partners, Shlaer and Mellor, Jacobson,
Wasserman et al, Rumbaugh, Reenskaug et al, and Colbert.

Wirfs-Brock, R.J. and Johnson, R.E., "Surveying Current Research in Object-
Oriented Design," The Communications of ACM, (33, 9) Sept. 1990, pp. 104-1124.

UNICOM. Approaches to Object-Oriented Analysis and Design.
tel: l 44 895 256 484. Ask the TOC and have a look at it.


Also commercially available:

An Evaluation of Object-Oriented Analysis and Design Methodologies (9)
J. Cribbs, C Roe, S. Moon
SIGS Books
[phone]
$149.

Object-Oriented Methodology Comparison Study (10 methodologies)
Berard, Booch, Coad/Yourdon, Colbert, Embley, IBM, Martin/Odell, Rumbaugh,
Shlaer/Mellor, Wirfs-Brock.  Also contains refs to several previous studies.
Berard Software Engineering
101 Lakeforest Blvd., Suite 360, Gaithersburg, MD 20877
Contact Person: Jim Youlio
Phone:        [phone]
Fax:          [phone]
email:        [e-mail]

[van den Goor et.al., 1992] G. van den Goor, S. Hong and S. Brinkkemper,
A Comparison of Six Object-oriented Analysis and Design Methods. Report
Center of Telematics and Information Technology, University of Twente,
the Netherlands, and Computer Information Systems Department, Georgia
State University, Atlanta, USA, 1992, 163 pages, US$ 70.

This report gives an in-depth analysis of six generally accepted
O-O methods, that are available in textbooks. The background, steps,
concepts, notations, and specification techniques of the methods
are extensively compared.

The six methods are:
-  Object Oriented Analysis & Object Oriented Design (OOA/OOD) of Coad &
      Yourdon (1991)
-  Designing Object Oriented Software (DOOS) of Wirfs-Brock et.al. (1990)
-  Object Modelling Technique (OMT) of Rumbaugh et.al. (1991)
-  Object Oriented Systems Analysis (OOSA) of Shlaer & Mellor (1988)
-  Object Oriented Design with Applications (OODA) of Booch (1991)
-  Object Oriented Analysis and Design (OOAD) of Martin & Odell (1992).

The comparison is performed by meta-modelling, resulting into detailed
information on the concepts of the methods (in EER notation) and on the
steps of the procedure of the methods (in Task Diagrams). Extensive
comparison tables of steps, concepts, techniques are included. Mappings of
the methodical concepts to the constructs of programming languages (C++,
Objective-C, Smalltalk-80, Object Pascal en CLOS) are given. A small
test case illustrates the application of the methods.

Order procedure:
Those who want to order the complete report (163 pp.) can order one by
specifying their postal address in an e-mail ([e-mail]) or fax
(+31.53.33.9605) attn. Sjaak Brinkkemper. The report will be send within
two weeks with an invoice for US$ 70. (seventy dollar; including shipping,
excl VAT).


3.8)  What Is the OMG/OMA/ORB/CORBA?
------------------------------------

Contents:
  (3.8.1)  Contact Information
  (3.8.2)  OMG Summary
  (3.8.3)  Mail Server Access
  (3.8.4)  OMG Publications
             - First Class (Bi-Monthly Newsletter)
             - Object Management Architecture Guide (OMA)
             - The Common Object Request Broker: Arch. and Spec. (Corba)
             - Pricing
  (3.8.5)  Implementations (Brief)
  (3.8.6)  Implementation Descriptions
  (3.8.7)  Books, Articles, And Literature


3.8.1  Contact Information
__________________________

Contact Person: Richard Soley (technical director) [e-mail]

FTP Sites:
  omg.org:pub/*
  omg.org:pub/NEC_DII/93-1-2.tar...            *CORBA (DII) (corba.ps.Z)
  omg.org:pub/OMG_IDL_CFE_1.2/bin*              idl.SunOS4.x, idl.Solaris2.x
  claude.ifi.unizh.ch:under pub/standards/spec  CORBA Spec

Headquarters:                            Marketing Office:
  492 Old Connecticut Path                 3823 Birchwood Drive
  Framingham, MA 01701                     Boulder, CO  80304
  Tel: [phone]                        Tel: [phone]
  Fax: [phone]                        Fax: [phone]


3.8.2  OMG Summary
__________________

From: [e-mail] (Richard Mark Soley)
Subject: OMG

In answer to your general question about the OMG, here's a brief overview.
Feel free to call, fax or email for more information.

        -- Richard Soley
           Vice President & Technical Director
           Object Management Group, Inc.
           and coincidentally, MIT '82, SM '85, PhD '89 (EECS)

The Object Management Group (OMG) is an international software industry
consortium with two primary aims:

(*) promotion of the object-oriented approach to software engineering
    in general, and

(*) development of command models and a common interface for the development
    and use of large-scale distributed applications (open distributed
    processing) using object-oriented methodology.

In late 1990 the OMG published its Object Management Architecture
(OMA) Guide document. This document outlines a single terminology for
object-oriented languages, systems, databases and application
frameworks; an abstract framework for object-oriented systems; a set
of both technical and architectural goals; and an architecture
(reference model) for distributed applications using object-oriented
techniques.  To fill out this reference model, four areas of
standardization have been identified:

1) the Object Request Broker, or key communications element, for
   handling distribution of messages between application objects in
   a highly interoperable manner;

2) the Object Model, or single design-portability abstract model for
   communicating with OMG-conforming object-oriented systems;

3) the Object Services, which will provide the main functions for
   realising basic object functionality using the Object Request Broker -
   the logical modeling and physical storage of objects; and

4) the Common Facilities will comprise facilities which are useful in
many application domains and which will be made available through OMA
compliant class interfaces.

The OMG adoption cycle includes Requests for Information and
Proposals, requesting detailed technical and commercial availability
information from OMG members about existing products to fill
particular parts of the reference model architecture.  After passage
by Technical and Business committees to review these responses, the
OMG Board of Directors makes a final determination for technology adoption.
Adopted specifications are available on a fee-free basis to members and
non-members alike.

In late 1991 OMG adopted its first interface technology, for the Object
Request Broker portion of the reference model.  This technology, adopted
from a joint proposal (named "CORBA") of Hewlett-Packard, NCR Corp.,
HyperDesk Corp., Digital Equipment Corp., Sun Microsystems and Object
Design Inc. includes both static and dynamic interfaces to an inter-
application request handling software "bus."

Unlike other organizations, the OMG itself does not and will not
develop nor sell software of any kind.  Instead, it selects and promulgates
software interfaces; products which offer these interfaces continue to be
developed and offered by commercial companies.

In order to serve OMG membership interested in other object-oriented systems
arenas besides the distributed system problem, the Group supports Special
Interest Groups for discussion of possible standards in other areas.  These
groups at present are:

        1) Object Oriented Databases;
        2) OO Languages;
        3) End-User Requirements;
        4) Parallel Processing;
        5) Analysis & Design Methodologies;
        6) Smalltalk; and
        7) Class Libraries.

Any company, university/research institution or individual, whether
end-user or vendor, can become a member of this body.  Administrative
details are given at the end of this paper.


3.8.3  Mail Server Access
_________________________

Information via Mail Server:
  Send the following commands in a letter to the mail server.

mail [e-mail]
help                             (how to use file server)
index                            (return a list of all available files)
get <file>                       (get files returned by  index)
log <info>                       (logs info on server)
address <e-mail address)         (use this address instead of sender)
list <directory> [match]         (index a directory, pattern 'match' files)
size <segment size>              (max file size to send)

list mail
list docs
get docs/doclist.txt
get docs/91-12-1.ps               CORBA spec [although it looks a little old]


Recommended (from the net):

mail [e-mail]
Subject:
help
index
list
list mail
list docs
get docs/doclist.txt


3.8.4  OMG Publications
_______________________

Below is from omg.org:pub/CORBA


> First Class (Bi-Monthly Newsletter)

First Class is OMG's non-commercial bi-monthly 28-page
newsletter. First Class provides current information on Object
Technology developments, both technically and commercially. First
Class offers an open editorial forum on numerous Object
Technology topics and issues.  This publication features
commentaries from software industry leaders, informative user
case histories, OT training information and the latest object-
oriented product announcements.  All OMG activities and the
ongoing development of the Object Management Architecture are
regularly reported.


> Object Management Architecture Guide (OMA)

The members of the OMG have a shared goal of developing and using
integrated software systems.  These systems should be built using
a methodology that supports modular production of software;
encourages reuse of code; allows useful integration across lines
of developers, operating systems and hardware; and enhance long-
range maintenance of that code.  As an organization, OMG believes
that the object-oriented approach to software construction best
supports their goals.  The OMA publication outlines the
groundwork for technology response to Request for Proposals (RFP)
and the adoption of specifications.


> The Common Object Request Broker: Arch. and Spec. (Corba)

The CORBA, as defined by the OMG's Object Request Broker (ORB),
provides the mechanisms by which objects transparently make
requests and receive responses. The ORB provides interoperability
between applications on different machines in heterogeneous
distributed environments and seamlessly interconnects multiple
object systems. The Common Object Request Broker Architecture and
Specification described in this published document is a self-
contained response to the Request for Proposals (RFP) issued by
the ORB Task Force of the OMG.

> Pricing

[Here's why you don't see the specifications posted on the net!  These are
 from the list of literature and periodicals listed in omg.org:pub/CORBA]

o I would like a one year subscription to First Class
    ______ for $40 U.S.,  ______ for $50 outside U.S.

o I would like to order  ______ copy(s) of the Object Management
  Architecture (OMA) Guide for $50 each.

o I would like to order  ______ copy(s) of the CORBA for $50 each.

o [Combinations]

Contact [e-mail] or [e-mail] for more of the same...


3.8.5  Implementations (Brief)
______________________________

> DEC ACA.  Maynard, MA

Runs on AIX,VMS,ULTRIX,,MS-WINDOWS,MAC,HP-UX,UNIX, NT(planned).


> HP ORB Plus and HP Distributed Smalltalk

Full implementation of the OMG CORBA 1.1 Object Request Broker.
Also DOMF

Hewlett-Packard
Distributed Computing Group
19447 Pruneridge Avenue
Cupertino, CA 95014-9974 (USA)
Ian Fuller [e-mail] [phone]


> HyperDesk (Westborough MA) HD-DOMS, [e-mail]

Runs on SPARC, HP/UX, IBM RS-6000, Data General Aviion, MS-Windows (client
API only), NetWare (planned, Novell owns part of HyperDesk).


> IBM SOM (System Object Model)

Available on AIX and OS/2.  See Distributed Computing Monitor, March 93 for a
detailed review.


> IONA Technologies, Dublin Orbix, [e-mail]

    runs on (Unix (Solaris 1.1) (now), DOS, Windows, NT (planned)


> ROLSCH CONSULTING (RC-ORB)

  implements ORB spec, DOS/Windows 3.1, 12 user license: $99.
  Ref: Datamation, LOOK AHEAD Section, August 1.  German Company.


> SuiteSoftware (Anaheim CA) SuiteDOME

    runs on VAX/VMS, Unix, PC


> Sun DOE


> Tivoli


> CS Dept. University of Zurich, Switzerland.  [e-mail]

    The ELECTRA Toolkit (not finished)


3.8.6  Implementation Descriptions
___________________________________

The OMG also has a (Corporate) Membership list and "known CORBA supporters"
list with their info package.


> The ELECTRA Toolkit

CS Dept. University of Zurich, Switzerland.  [e-mail]
The ELECTRA Toolkit

Subject: ORB Implementations
Date: Tue, 4 May 1993 13:12:36 +0200 (MET DST)
From: Silvano Maffeis <[e-mail]>

  something like an Object Broker, but it is *not* CORBA compatible (yet).
  Electra is a research project and not available yet.

  Its a toolkit for building failure resilient, distributed applications
  in C++. It supports object-groups, virtual synchrony, multithreading
  etc. Electra is based on the HORUS toolkit (which is "the new ISIS
  implementation" developed at Cornell, Ithaca NY.)
  An overview paper to electra is available from:
  ftp.ifi.unizh.ch: pub/techreports/electra.ps.Z


> HD_DOMS

HD-DOMS (HyperDesk Distributed Object Management System).  A
CORBA-compliant DOMS.  Includes a GUI API driver for prototyping and
exercising objects, a bundled object database for persistent object
storage, a Kerberos-based authentication service, a location service, a
set of base classes to speed development, and a test script language.
Revision 1.0 has been shipping since beginning of '92.  Revision 1.1
(which includes support for CORBA's static client interface) is available
now, and a NetWare version is in the works.  Submitted a C++ language
mapping for IDL to the OMG recently.

HyperDesk Corporation
2000 West Park Drive
Westboro, MA 01581
[phone]


> HP ORB Plus and HP Distributed Smalltalk

From: [e-mail] (Daryl Odnert)
Subject: HP ORB Plus and Distributed SmallTalk
Summary: Official HP Press release on HP ORB Plus and DST 2.0
Date: Thu, 30 Sep 1993 20:13:48 GMT
Organization: Hewlett-Packard

  ============================================================================
  SUBJECT:  HP INTRODUCES DISTRIBUTED-COMPUTING SOLUTION FOR BUILDING
            SCALABLE, OBJECT-ORIENTED APPLICATIONS
  DATE:     September 27, 1993
  ----------------------------------------------------------------------------

   PALO ALTO, Calif.--(BUSINESS WIRE) via First! -- Hewlett-Packard Company
 today introduced a distributed-computing solution for building scalable,
 object-oriented applications.

   With HP ORB Plus, programmers can develop scalable, object-based
 applications that can be distributed throughout the enterprise.  HP also
 introduced an enhanced version of HP Distributed Smalltalk.

   HP ORB Plus and HP Distributed Smalltalk are major components of HP's
 overall distributed-computing strategy, which is designed to give customers
 integrated, desktop access to enterprise-wide information and resources in
 distributed heterogeneous systems environments.  Of all computer companies,
 HP believes it is best positioned to help customers take advantage of
 distributed computing. HP provides a wide variety of distributed-computing
 products, understands how to help customers adopt new technology for maximum
 business benefit, and offers worldwide support and training programs,
 ranging from analysis and design to deployment.

   HP ORB PLUS:  CORBA AND DCE COMBINED

   HP ORB Plus is the only environment that combines the complete CORBA 1.1
 specification from the Object Management Group with the DCE standard from
 the Open Software Foundation(tm) as its transport mechanism.  DCE is
 designed to let developers write one application and then deploy it --
 without modification -- on any other system that supports DCE.  HP ORB Plus
 reduces the complexity of developing distributed applications so programmers
 can concentrate on the application itself without needing to know multiple
 operating systems, networking protocols or where application objects are
 stored.

   The DCE (Distributed Computing Environment) standard provides an
 integrated set of services that can be used separately or together to
 provide a distributed computing environment that's easy to administer.  The
 CORBA (common-object-request-broker architecture) specification provides a
 standard for how objects (in applications, repositories or class libraries)
 make requests and receive responses across a distributed network.

   HP ORB PLUS DETAILS

   HP ORB Plus consists of several components: the Distributed Object
 Management Facility (DOMF), object services, developers' and administrative
 tools, and sample applications.  HP's DOMF provides a location-transparent
 object-communication mechanism across heterogeneous networks by using the
 DCE standard.  This object- enabling technology specification was jointly
 developed with SunSoft. By following a common specification, HP and SunSoft
 have made it easier for their customers to port applications between their
 platforms.

   In addition, HP is working with IBM to integrate HP's DOMF with IBM's
 System Object Model with extensions for distribution.  This integration will
 eventually provide users with complete scalability, portability and
 interoperability of distributed applications across HP and IBM platforms.
 This is part of the companies' planned approach toward a standards-based,
 "plug-and-play"  object-oriented environment.  This will give developers,
 system administrators and end users language-neutral, enterprise-wide,
 heterogeneous support for building, managing and using distributed object-
 oriented applications.

   "We're so convinced of the value of object technology that we're staking
 our entire company on it,"  said Richard Tanler, president and chief
 executive officer of Information Advantage, Inc.  "Our object-based
 applications for retailers provide the means to a competitive business edge.
 We plan to use HP ORB Plus to develop new object-based products that
 retailers can distribute to end users throughout headquarters, all chain
 stores, and warehousing and distribution operations."

   HP DISTRIBUTED SMALLTALK 2.0

   In a related announcement, HP introduced Version 2.0 of HP Distributed
 Smalltalk.  This toolset works with VisualWorks from ParcPlace Systems to
 provide programmers with a rapid development environment for creating and
 running distributed applications.  These applications can use object
 databases (currently OpenODB from HP and Gemstone from Servio) as their
 storage mechanism to facilitate the reuse of objects.

   Applications built using HP Distributed Smalltalk currently run without
 modification on HP, Sun and IBM UNIX(R) system-based workstations.  They
 also will run on Apple Macintosh computers and on any PC running the Windows
 3.1 or Windows NT operating systems from Microsoft(R) Corp., once
 VisualWorks 2.0 is released (expected within two months.)

   New HP Distributed Smalltalk 2.0 features include the following:

   --  easier deployment, with the ability to run multiple HP
       Distributed Smalltalk-based applications on a single system;
   --  up to 400 percent increased performance, through quicker
       sending and receiving of remote messages, and reusable
       object libraries;
   --  run-time version, for full production deployment; and
   --  easier development, with remote object browsing so
       developers can find and use objects more quickly.

   TECHNICAL DETAILS AND AVAILABILITY

   HP's DOMF includes the object request broker, interface- definition-
 language compiler, static and dynamic invocation interface and interface
 repository.  In addition to these OMG-specific features, most developers
 writing distributed, object-oriented applications require additional
 interfaces to use objects effectively.  So developers don't need to create
 their own, HP has supplied several object-service interfaces for developers
 to use. That's why HP ORB Plus includes OMG interfaces and implementations
 for properties, life cycle, associations, event notification and naming.

   HP's limited release of HP ORB Plus to key developers is designed so that
 customer input can be incorporated into the product early in its development
 cycle.  The initial version will work with the C++ programming language.
 For the generally available Developer's Kit, C++, C and Smalltalk
 interoperability is planned so objects written in different languages can be
 combined into one application.  The Developer's Kit is scheduled to be
 available mid- 1994; prices will be announced then.  HP ORB Plus runs on the
 HP Apollo 9000 Series 700 workstations and HP 9000 Series 800 business
 servers.

   Hewlett-Packard Company is an international manufacturer of measurement
 and computation products and systems recognized for excellence in quality
 and support.  The company's products and services are used in industry,
 business, engineering, science, medicine and education in approximately 110
 countries.  HP has 94,900 employees and had revenue of $16.4 billion in its
 1992 fiscal year.

 EDITORIAL CONTACTS:
    Hewlett-Packard Company
    Lynne Hanson, 408/447-1415, Cupertino, Calif.
    Jill Kramer, 408/447-4275, Cupertino, Calif.

 ==================
 Daryl Odnert       [e-mail]
 Distributed Computing Program
 Hewlett-Packard Company
 Cupertino, California


> Iris RDOM

From: [e-mail] (Robert Cooper)
Subject: Re: DCE vs. CORBA
Reply-To: [e-mail]
Product: Isis Reliable Distributed Object Manager(tm) (RDOM)
Company: Isis Distributed Systems, Inc., Ithaca NY, USA.

Isis RDOM(tm) is a fault tolerant distributed ORB platform for reliable
multi-lingual object-oriented applications. RDOM provides an "object group"
paradigm for constructing complex applications out of collections of
cooperating objects. RDOM is built on top of the Isis Distributed
Toolkit(tm). RDOM provides interfaces from Smalltalk (Parcplace),
Objective-C, and C++, and runs on most Unix workstations. RDOM is currently
not CORBA compliant, but will be brought to compliance during 3Q93.

Status:

RDOM has been at beta test sites since January. General release of
the Smalltalk and Objective-C language interfaces is expected in June.
The C++ interface in August. Customers include AMD, Consilium and Swiss
Bank Corp).


> Orbix

Orbix
Iona Technologies Ltd.
O'Reilly Institute
Westland Row
Dublin 2
Ireland

"ORB, CORBA compliant.
Product launched June, 93 at the OMG Object World.
Now shipping.  Provides C++ support (gives distributed
C++ programming using CORBA);  C++-IDL binding was jointly submitted with
SunSoft/HP to OMG recent call. "
etc etc

Chris Horn,                                        tel: [phone]
Iona Technologies,                                 fax: [phone]
O'Reilly Institute,                                email: [e-mail]
Westland Row
IRL - Dublin 2


3.8.7  Books, Articles, And Literature
--------------------------------------

This section is expected to grow considerably in the future.

"Distributed Object Computing With CORBA", C++ Report, July/August 1993

The Object Database Standard: ODMG-93
edited by: R.G.G. Cattell
published by Morgan Kaufmann Publishers, San Mateo, California
[Covers CORBA standards with respect to OODBs]


3.9)  Why Is Garbage Collection a Good Thing?
---------------------------------------------

  From: Paul Johnson ([e-mail])

Garbage collection (GC) is a facility in the run-time system associated with a
language which will automatically reclaim objects which are no longer used.
OO Languages which require garbage collection include Eiffel, Smalltalk and
CLOS.  C and C++ can have garbage collection retrofitted (see [3] below).
[Ada has switchable GC, too -bob]

Without GC programmers must explicitly deallocate dynamic storage when
it is no longer needed (in C this is done by a call to free(3)).
There are a number of problems with this:

1: Bugs due to errors in storage deallocation are very hard to find,
   although products are available which can help.

2: In some circumstances the decision about whether to deallocate
   storage cannot be made by the programmer.  Drawing editors and
   interpreters often suffer from this.  The usual result is that the
   programmer has to write an application-specific garbage collector.

3: An object which is responsible for deallocating storage must be
   certain that no other object still needs that storage.  Thus many
   modules must co-operate closely.  This leads to a tight binding
   between supposedly independent modules.

4: Libraries with different deallocation strategies are often
   incompatible, hindering reuse.

5: In order to avoid problems 3 and 4, programmers may end up copying
   and comparing whole objects rather than just references.  This is a
   particular problem with temporary values produced by C++ overloaded
   operators.

6: Because keeping track of storage is extra work, programmers often
   resort to statically allocated arrays.  This in turn leads to
   arbitrary restrictions on input data which can cause failure when
   the assumptions behind the chosen limits no longer apply.  For
   instance many C compilers limit expression nesting, identifier
   length, include file nesting and macro stack depth.  This causes
   problems for programs that generate C.

One partial solution to a lack of GC is reference counting.  In this
scheme each object keeps a count of references to it.  When this count
drops to zero the object is automatically deallocated.  However this
is inefficient (swapping two references will result in three
decrements, three increments and six comparisons) and cannot reclaim
circular data structures.  Two systems that use a reference count GC
are the Interviews C++ graphics library and the Unix file system (the
link count).

Opponents of GC reply that it introduces an overhead which is
unacceptable in some applications.  However the overhead of manual
storage deallocation is probably as high as GC.  GC algorithms are
also available with good real-time behaviour.

[Further, GC can perform compaction improving locality of reference.]

Further Reading:

[1] "Object-Oriented Software Construction" by Meyer puts the argument
for GC.

[2] "Uniprocessor Garbage Collection Techniques," by Paul R. Wilson,
in Memory Management (proceedings of 1992 Int'l Workshop on Memory
Management, Sept. 1992, St. Malo, France, Yves Bekkers and Jacques Cohen,
eds.), Springer Verlag Lecture Notes in Computer Science #637.

This is an excellent summary of the state of the art in GC algorithms.  This
and other papers about garbage collection are available in PostScript via
anonymous ftp (cs.utexas.edu:pub/garbage/gcsurvey.ps.  [See APPENDIX E]

[3] "Garbage Collection in an Uncooperative Environment" by Boehm and
Weiser.  Software --- Practise and Experience vol 18(9), pp 807-820.
Sept 1988.  This describes GC in C and C++.

3.10)  What Can I Do To Teach OO To The Kids?
---------------------------------------------

Smalltalk (in its original 1972 version) was initially intended to make
computer programming easy enough for children.  The idea was that manipulating
objects was something more intuitive and natural than coding procedures.

Other entries or suggestions are welcome, please send to the author of the FAQ.