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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,d58628d74c8614d4
X-Google-Attributes: gid103376,public
From: adam@irvine.com
Subject: Re: Active Iteration (was: How to use abstract data types)
Date: 1998/05/13
Message-ID: <6jcov8$ske$1@nnrp1.dejanews.com>#1/1
X-Deja-AN: 352937972
X-Http-User-Agent: Mozilla/3.0 (X11; I; Linux 2.0.18 i586)
Organization: Deja News - The Leader in Internet Discussion
X-Article-Creation-Date: Wed May 13 18:32:07 1998 GMT
Newsgroups: comp.lang.ada
Date: 1998-05-13T00:00:00+00:00
List-Id: <comp.lang.ada>


Matthew, thanks for all the information.  It helps to be exposed to a
number of different approaches, so once I understand them all, I can
pick which one seems best.

A question about one thing you wrote:

> The dynamic approach is a bit more flexible, but it could be made to work
> (but see below).  Notice that you've already made a static commitment in
> your case statement (which is by definition static).  The
> Let_Client_Play_With_Library could have been made into a generic, and
> instantiated once per library (ie once per brach of the case statement).
> Something like:

> procedure Let_Client_Play_With_Test_Lib is
>    new Let_Client_Play (Test_Library...);
>
> procedure Let_Client_Play_With_Another_Test_Lib is
>    new Let_Client_Play (Another_Test_Library...);

Regarding the example at LRM 3.9.3(15-16):

    package Sets is
        subtype Element_Type is Natural;
        type Set is abstract tagged null record;
        function Empty return Set is abstract;
        function Union(Left, Right : Set) return Set is abstract;
        function Intersection(Left, Right : Set) return Set is abstract;
        function Unit_Set(Element : Element_Type) return Set is abstract;
        procedure Take(Element : out Element_Type; From : in out Set)
             is abstract;
    end Sets;

    Notes on the example: Given the above abstract type, one could
    then derive various (nonabstract) extensions of the type,
    representing alternative implementations of a set.  One might use
    a bit vector, but impose an upper bound on the largest element
    representable, while another might use a hash table, trading off
    space for flexibility.

It seems to me that, if your two choices are a bit vector and a hash
table, it's likely that other modules in the program that use a Set
would make this choice statically, because they'd already have an idea
of the upper bound on elements in the set.  My question: Would you
therefore choose instead to use a generic to implement a "Set"?  If
not, but if you would choose to use a generic to implement a Library
in my example, what's is the difference between the two examples that
would cause you to use different language constructs to implement
them?

                                -- thanks, Adam

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading