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=3.8 required=5.0 tests=BAYES_00,INVALID_MSGID, RATWARE_MS_HASH,RATWARE_OUTLOOK_NONAME autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,27df3b4190d953db X-Google-Attributes: gid103376,public From: "Nick Roberts" Subject: Re: statically compatible access discriminants in derivation Date: 1998/01/16 Message-ID: <01bd2219$965dd320$25fc82c1@xhv46.dial.pipex.com>#1/1 X-Deja-AN: 316383984 Content-Transfer-Encoding: 7bit References: <69gucb$l9k$1@uuneo.neosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Organization: UUNet UK server (post doesn't reflect views of UUNet UK) Newsgroups: comp.lang.ada Date: 1998-01-16T00:00:00+00:00 List-Id: I think if you look closely at the wording of 4.9.1(4), you will see that in the derivation definition type object( board : access device_instance.object'class ) is new unit_if.object( board ) with null record; the subtype of the board in the parent type (unit_if.object) is 'statically compatible' with the subtype of the new discriminant, because (a) it is an access type, and (b) the parent type's discriminant's subtype is unconstrained. All class-wide types are unconstrained. So I believe you can do what you put in the example. I cannot claim to be authoritative here: others may know better than me (please, don't laugh, I have my pride you know :-). -- Nick Roberts Croydon, UK Proprietor, ThoughtWing Software; Independent Software Development Consultant * Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 * *** Eats three shredded spams every morning for breakfast *** Pat Rogers wrote in article <69gucb$l9k$1@uuneo.neosoft.com>... > Given a tagged type with an access discriminant designating a > classwide type, and a child type derived from this parent type, is it > possible to declare an access discriminant in the child type that is > statically compatible with the parent's access discriminant, while having > the child's access discriminant designate a classwide type further down in > the parent's designated derivation class? > [etc...]