From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!UMDB.BITNET!BRAD
From: BRAD@UMDB.BITNET.UUCP
Newsgroups: comp.lang.ada
Subject: re: generics vs. private types
Message-ID: <8706030336.AA13065@ucbvax.Berkeley.EDU>
Date: Tue, 2-Jun-87 21:54:47 EDT
Article-I.D.: ucbvax.8706030336.AA13065
Posted: Tue Jun  2 21:54:47 1987
Date-Received: Fri, 5-Jun-87 03:11:15 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
List-Id: <comp.lang.ada>

In the discussion of implementing a class of objects as either a
generic finite state machine package (with no generic formal parameters) or
as an abstract data type package, I see the following tradeoffs.
(sorry that I can't reproduce the code, but I'm sending from a brain-damaged
IBM 4341...)

Generic package encapsulating a finite state machine (FSM):
  This is very much in line with the Simula and Smalltalk approach for
creating a class of objects.  Each instance of the class (here, each
instantiation of the generic) actually encapsulates both the state information
i.e. the values on the stack and the stack attributes; and also encapsulates
the operations on the object, i.e. push, pop, etc.  This promotes abstraction,
information hiding, modularity, uniformity, etc.
  But, there is one difference from the Simula/Smalltalk model in that the
class (collection) is anonymous.  Since the class has no name, we can
create individual objects, but not use them to create larger structures.
For example I can have many distinctly referenced stacks, but I cannot
create an array of stacks or a list of stacks.

Package exporting an abstact data type (ADT):
   This still has abstraction and information hiding (i.e. private types),
but here the operations (e.g. push, pop) reside with the class (package)
and not with the individual object (as in a truly object oriented language
such as Smalltalk or even CLU or Simula).  The state information resides
separately in the Ada variable declared from Stack_Package.Stack.  On the
other hand, we now have a true Ada type that may be used to build larger
abstractions (e.g. a stack of stacks or an array of stacks).

Overall, I tend to use the latter approach since building abstractions
on other abstractions in a fundamental design tool (especially in OOD).

Further things to consider:  try replacing the generic package approach
with a task type.  What are the tradeoffs?  When is this useful?
Also:  what are the limitations when this design technique is combined
with data abstraction in building sophisticated Ada generics?

Brad Balfour
EVB Software Engineering, Inc.
brad%umdb.bitnet@umd2.umd.edu    (I hope)

Aside to Doug Bryan:  Actually, the real answer to the above is for
Ada to have a package type the way that it has a task type now.  Let's
lobby for it for Ada 9x.