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,3e9f0e99a5a40441 X-Google-Attributes: gid103376,public From: eachus@spectre.mitre.org (Robert I. Eachus) Subject: Re: Deriving from non-null abstract type Date: 1995/03/29 Message-ID: #1/1 X-Deja-AN: 100540701 references: <3lbh2q$8ov@israel-info.datasrv.co.il> organization: The Mitre Corp., Bedford, MA. newsgroups: comp.lang.ada Date: 1995-03-29T00:00:00+00:00 List-Id: In article <3lbh2q$8ov@israel-info.datasrv.co.il> benari@zeus.datasrv.co.il (Moti Ben-Ari) writes: > Of course, you can't create a value of the abstract type, > but it turns out that it is impossible to create a value > of the derived type... Not quite true, but it is a very good question. It is illegal to create an object or an aggregate of an abstract type: > D: Derived_Type := (G with S); > because G would have to be an aggregate of an abstract type > which is illegal. The only thing you can do is: ...but G is not required to be an aggregate, it is required to be a subtype name or an expression. Also, there is no requirement to use an extension aggregate. If you want to initialize the entire record--and have the visibility to do it--you can use a simple aggregate: D: Derived_Type := (G,S); Also Moti Ben-Ari discussed the subtype case: > D: Derived_Type := (Abstract_Type with S); > which means that the component General_Info has to > be initialized in a separate statement. ...but missed the fact that the part of the object corresponding to the parent type does get initialized if the parent type has default expressions. Also, the record component association list can override any default assignments to components of the parent type, so it is possible, just not required, to initialize all components. An interesting philosophical question is whether the prohibition on aggregates of an abstract type in 3.9.3(7) was intended to apply to this case. I suspect not, but I don't think the ARG should consider "fixing" it. There doesn't seem to be any lost functionality--and conversely it doesn't seem difficult to allow--but I don't see any advantage to a change which is purely a syntactic patch to make extension aggregates easier to read in some unusual cases. For those who care, going back to Moti's example, the legal way to initialize the entire record using an extension aggregate is to say: D: Derived_Type := (Abstract_Type with General_Info => G, Special_Info => S); instead of: D: Derived_Type := ((General_Info => G) with Special_Info => S); > Is there some way of creating a value that I don't see? Yep, see above. Two of them. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...