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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c6150ba97747373e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-17 14:16:30 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn1feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi.com!rwcrnsc51.ops.asp.att.net.POSTED!not-for-mail Message-ID: <3D0E51F3.7000301@attbi.com> From: "Robert I. Eachus" Organization: Eachus Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: runtine instanciation References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.61.239.24 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc51.ops.asp.att.net 1024348589 24.61.239.24 (Mon, 17 Jun 2002 21:16:29 GMT) NNTP-Posting-Date: Mon, 17 Jun 2002 21:16:29 GMT Date: Mon, 17 Jun 2002 21:16:29 GMT Xref: archiver1.google.com comp.lang.ada:26183 Date: 2002-06-17T21:16:29+00:00 List-Id: 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. ;-)