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,7638bc607ef4fdc8
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Limits for Generic Formal Package paremeters with tagged types?
Date: 1996/07/19
Message-ID: <EACHUS.96Jul19140335@spectre.mitre.org>#1/1
X-Deja-AN: 169845286
references: <DurCzM.7v2@plato.ds.boeing.com>
organization: The Mitre Corp., Bedford, MA.
newsgroups: comp.lang.ada
Date: 1996-07-19T00:00:00+00:00
List-Id: <comp.lang.ada>



In article <DurCzM.7v2@plato.ds.boeing.com> scott@plato.ds.boeing.com (Scott Moody) writes:

   > This is long winded, so to jump to the question about 
   > Ada-95 and generic formal parameters, proceed
   > to ADA-95 LIMITATION at the end..

   > I am trying to design a way for various sub-systems to all
   > manipulate a global database of information but in a manner that
   > supports the object-oriented extensibility concepts. For example,
   > this global database will have more or less fields in it based on
   > the final configuration - but the existing sub-systems don't care
   > except in a certain contrained way: they require that certain
   > data fields exist during their execution.

   This is not an easy one, but the problem is that you have fixed on
a certain method of combining abstractions and inheritance.  To solve
your problem you need to use class-wide types and dispatching in the
info_manager.  However, you seem to want to create an array of fixed
size objects.  Ada won't allow you to do this directly, since the
maximum size of the all objects of the class can't be known.  So you
have to do Unchecked_Conversions inside of the info manager--if you
insist on an array of fixed sized objects.

   If you want to stay at a high level, the answer is to have your
info_manager manage an array of class-wide pointers.  You can then
have dispatching operations to allocate and free these pointers, and
assuming I know where you are coming from, all the designated objects
will be created once, during initialization, and there will be no use
of the heap:

    type Symbol is abstract tagged null record with private;
    type Pointer is access all Symbol;
    ...
    procedure Free(P: in out Pointer);
    -- the body of Free will dispatch based on the type of P.all.
    -- there is no allocate function declared, since Ada rules would
    -- require overriding in all cases, and you will normally want to
    -- have different parameters for each allocate.
  private
    type Symbol is ...
    -- Note that you will need fields in Symbol to be used by the
    -- info_manager, and will want to have initial values for them.
    -- This could be as little as a single In_Use bit, or a pointer to
    -- self. 
    procedure Manage(S: in out Symbol) is abstract;
    -- called by Free to do type specific operations.

-- In another package...
    type Vehicle_Symbol is new Symbol with private;

  private
    Vehicle_Array: array(1..N) of Vehicle_Symbol;
    -- there only can be N objects of type vehicle symbol.  However
    -- this does not include car_symbols which will be found in their
    -- own (private) array.
    
  Sketchy, and includes a lot of things like anonymous arrays I
wouldn't use in real code, but it should give you the idea.  You can
make the info_manager a generic, but there is no need to.  It's
differences in behavior will come through inherited operations.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...