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,27df3b4190d953db X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: statically compatible access discriminants in derivation Date: 1998/01/17 Message-ID: #1/1 X-Deja-AN: 316878831 Sender: news@inmet.camb.inmet.com (USENET news) References: <69gucb$l9k$1@uuneo.neosoft.com> X-Nntp-Posting-Host: houdini.camb.inmet.com Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1998-01-17T00:00:00+00:00 List-Id: Pat Rogers (progers@acm.org) wrote: : ... : with device_instance; : with unit_if; : package unit_instance is : type object( board : access device_instance.object'class ) is : new unit_if.object( board ) with null record; : procedure foo( this : in out object ); : end unit_instance; : That way I can directly reference X within foo: : package body unit_instance is : procedure foo( this : in out object ) is : begin : this.board.x := 0; : end foo; : end unit_instance; : As I read the RM, it seems that 3.7(15) requires them to statically match, "compatible", not "match" ---------^^^^^ : and 4.9.1 says that they can not. Is there a way around this? Reread 3.7(15). It uses the term "statically compatible" not "statically match" Because anonymous access subtypes are always unconstrained, there is no problem of compatibility, presuming the expression used in the constraint is convertible to the anonymous access type (which it is). : As I mentioned, I could just inherit the discriminant 'board' designating : device_if.object'class, and convert to device_instance.object'class, but : would rather have it checked when the objects are declared. : Any ideas? The code above should compile. Is it being rejected by your favorite Ada compiler? You might post the error messages you are receiving. Perhaps the real problem is elsewhere. -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA