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,5606d8433901738c X-Google-Attributes: gid103376,public From: jvl@ocsystems.com (Joel VanLaven) Subject: Re: Allocating "initialized" limited types... Date: 1996/09/04 Message-ID: <1996Sep4.183415.17277@ocsystems.com>#1/1 X-Deja-AN: 178490723 references: organization: OC Systems, Inc. newsgroups: comp.lang.ada Date: 1996-09-04T00:00:00+00:00 List-Id: Jon S Anthony (jsa@alexandria) wrote: : > > >Doesn't help and is much more prone to errors (forget one of those fields???> : > > Maybe you're really asking why limited types don't allow aggregates? : > > The "don't forget fields" feature is a property of aggregates, not : > > allocators. It's not clear how one could deal with access discrims in : > > an aggregate. : > : > No, I really think what I was after is the above bit about limited : > public and non limited private views of tagged types. To me, not : > allowing an aggregate is obvious: it is an assignment to the object : > (not to its separate fields!) and thus illegal for limited types. : Well, here I'm just in the weeds, having become side tracked by the : public/private limited/non-limited tagged type issue. This really has : nothing to do with what I had in mind, which is really captured by the : notion of "in place" creation. As I did not know much about limited types, and this seemed so interesting and potentially important to me as a new Ada95 programmer, I read up and looked around at this. Here is an interesting take on limited types from the Annotated Ada95 Reference Manual <7.5:1a> "The concept of the value of a limited type is difficult to define, since the abstract value of a limited type often extends beyond its physical representation. In some sense, values of a limited type cannot be divorced from their object. Th value is the object." This leads me to think that disallowing any sort of "total" initialization makes sense to preserve the powerful abstraction involved. However, this is not what you want. So, I bring your attention to the concept of a record. The obvious concept of a record is a way of grouping types into a more complicated type. If this were the entire extent of a record we would be fine. The problem is that records are given special meaning and usage for tagged types, interfering with the natural nice things that can be done with them like aggregate assignment/initialization, etc. So, consider that the record is almost undoubtedly in no way actually taking up extra space in the running program, just as the "extraneous type conversion" isn't really there (just at compile time, as a sort of compiler directive), and we come to my solution, albeit possibly a "hack" :). In order to extend T to C, define a new record type oh say c_rec like type c_rec is record a:t1; b:t2; ... end reocrd; type c is new t with record rec:c_rec; end record; This allows you to use the nice aggregate assignment features of Ada without being stuck on the idea of tagged types as records, using: obj_ref.rec:=c_rec'(a1,b1,...); Using this method as well as the access type conversion you mentioned earlieri, possibly isolated into a self-defined "in place" creation subprogram ought to work fairly well. The extra record type ought not add run-time costs, just like the type conversion. It might not give you be the most natural way to do what you want, but then again limited types are severely restricted for good if obscure reasons. Perhaps you'd rather use controlled types...? If this is a stupid idea or I missed the point, as is quite possible, don't worry, my ego doesn't hang on this at all :) BTW I really enjoy your posts, and it is good to here from people doing user-level commercial applications in my favorite language, keep it up! -- While the opinions in this message do not represent the opinions of my -- employers, the technical accuracy or lack there of does represent the -- quality of my higher education. -- -- Joel VanLaven -- -- Joel VanLaven