comp.lang.ada
 help / color / mirror / Atom feed
From: "Robert I. Eachus" <rieachus@attbi.com>
Subject: Re: runtine instanciation
Date: Mon, 17 Jun 2002 21:16:29 GMT
Date: 2002-06-17T21:16:29+00:00	[thread overview]
Message-ID: <3D0E51F3.7000301@attbi.com> (raw)
In-Reply-To: mailman.1024325702.27478.comp.lang.ada@ada.eu.org

Robert C. Leif wrote:


> 2) Even if I create a tagged type for my record, I still have to fill
> its fields. As I previously stated, the allowable data types and their
> methods have been previously compiled. I realize that one could use
> access types. However, I am hoping for a very simple static solution
> based on the use of the compiler...


I am going to discuss this from a language lawyer viewpoint, so first I 
need to point out that in Ada, compile-time and link-time are some 
amorphous concepts dealing with time before the environment task is 
created, and static is a concept that has nothing to do with 
compile-time vs. run-time, but with error-checking requirements.  So be 
warned.

First, declaring a heterogenous tagged data type with up to fifteen 
potentially different compontents is not all that difficult in Ada.  In 
fact, in this case I actually prefer a more Ada 83ish solution:


type Field is (Name_Field, Address_Field, ...);

type Field_Set is array Field of Boolean;

type Field_Index is range 1..Field'Last + 1;

type Field_Record(F: Field) is record
   case F is... end case; end record;

type Field_Wrapper is record R: Field_Record; end record;

type Field_Array is array (Field_Index range <>) of Field_Wrapper;

type DB_Record (Fields: Field_Set) is record
   FA: Field_Array; end record;

A lot of gratutitous seeming declarations there, but the net result is 
that you can create a record containing any subset of the fifteen 
potentially different fields at run-time. Some compilers, notably Alsys 
went to a lot of trouble to create decent data structures to support 
such objects--but that is a compiler issue not a language issue.

However, as I understand your concerns, you don't want the field 
definitions wrapped up all in one place.  What I would do is create a 
data structure something like:

type Field_Name is (Name_Field, Address_Field, ...);

type Field (Name: Field_Name) is abstract tagged...;

type Field_Pointer is access all Field;

type Data_Record is array(Field) of Field_Pointer;
-- These only exist in memory, and then only when working with actual
-- records.  So having a fixed array size with meaningful indexes will 
-- probably shrink code size more than any additional memory usage for
-- active structures of this type.

Now when you read from the database, your routines unpack the records 
and fill in the correct access values.  Fields not used by that record 
will contain null pointers, and you should be able to get to and from a 
decent disk storage format with 'Read and 'Write.

Each field type can have its own dll, and users can redefine these as 
they will.  But please, if you are going to do this while the program is 
executing, remember the two primary rules about such records from Multics:

     1) Any record type that is subject to change shall have a version 
number in the record format.  This allows newly linked routines to tell 
if they are looking at the old or new format for any record.

     2) All persistant record types are subject to change. ;-)




  reply	other threads:[~2002-06-17 21:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-15 11:43 runtine instanciation Immanuel Scholz
2002-06-15 15:20 ` Simon Wright
2002-06-16 23:07 ` Dmitry A.Kazakov
2002-06-17  3:16   ` Robert C. Leif
2002-06-17 22:04     ` Dmitry A.Kazakov
2002-06-17 14:54       ` Robert C. Leif
2002-06-17 21:16         ` Robert I. Eachus [this message]
2002-06-18 22:35         ` Dmitry A.Kazakov
2002-06-17 10:07   ` Antonio Duran
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox