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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e92d558e5b77fce2 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.68.226.10 with SMTP id ro10mr12276893pbc.6.1328568059107; Mon, 06 Feb 2012 14:40:59 -0800 (PST) Path: lh20ni268316pbb.0!nntp.google.com!news1.google.com!postnews.google.com!k6g2000vbz.googlegroups.com!not-for-mail From: Simon Belmont Newsgroups: comp.lang.ada Subject: Re: Building limited types through nested creator functions Date: Mon, 6 Feb 2012 14:33:39 -0800 (PST) Organization: http://groups.google.com Message-ID: References: <40048c5a-ecf5-43e6-8c76-a294d0c333d1@l14g2000vbe.googlegroups.com> <1f36269b-78fa-4a8a-90c8-104c932e8658@d15g2000yqg.googlegroups.com> NNTP-Posting-Host: 24.218.138.255 Mime-Version: 1.0 X-Trace: posting.google.com 1328568058 25159 127.0.0.1 (6 Feb 2012 22:40:58 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 6 Feb 2012 22:40:58 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: k6g2000vbz.googlegroups.com; posting-host=24.218.138.255; posting-account=ShYTIAoAAABytvcS76ZrG9GdaV-nXYKy User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: ARLUEHNKC X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; InfoPath.2),gzip(gfe) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-02-06T14:33:39-08:00 List-Id: On Feb 6, 2:11=A0pm, Shark8 wrote: > On Feb 5, 4:03=A0pm, Simon Belmont wrote: > > > > > > > Hi, > > > Consider two limited record types, inner and outer, with the former > > nested inside the latter. =A0If the records are public, then code can > > initialize the outer by specifying an aggregate for the inner, as in: > > > type Inner is limited > > =A0 record > > =A0 =A0 e : Integer; > > =A0 end record; > > > type Outer is limited > > =A0 record > > =A0 =A0 i : Inner; > > =A0 end record; > > > o : Outer :=3D Outer'(i =3D> Inner'(e =3D> 42)); > > > However, if types are made private, suitable functions must be > > provided to make the appropriate objects. =A0If just Inner is private, > > then this can be done (assuming simple creator functions that just > > create the objects with the given values): > > > o : Outer :=3D Outer'(i =3D> Make_Inner(arg =3D> 42)); > > > but if both are private, then the following: > > > o : Outer :=3D Make_Outer (arg =3D> Make_Inner(arg =3D> 42)); > > > ends up being illegal, because in the code: > > > function Make_Outer (arg : Inner) return Outer is > > begin > > =A0 return Outer'(i =3D> arg); > > end Make_Outer > > > would end up trying to copy a limited type. =A0For the cases in which a= n > > existing object is passed in, this would be the appropriate action, > > but for cases where the object is built-in-place into the argument, > > clearly the intended behavior is to build it in place to the resultant > > object. =A0It's easy enough to use an access value, but as unnecessary > > use of access values is generally discouraged, I was just curious if > > there was an alternative mechanism to achieve the desired effect. > > > -sb > > Try this: > > Function Make_Inner( I: Integer ) Return Inner is > begin > =A0 =A0 Return Result : Inner:=3D Inner'( E =3D> I ); > end Make_Inner; > > Function Make_Outer( I: Integer ) Return Outer is > begin > =A0 =A0 Return Result : Outer:=3D Outer'( I =3D> Make_Inner(I) ); > end Make_Outer; > > The 'trick' is to use all the parameters used in make_inner plus > whatever is needed in the Outer record for the parameter-list of > Make_Outer; thus you avoid all copying restrictions as you are really > building-in-place.- Hide quoted text - > > - Show quoted text - This was my original plan, but the worry is that this doesn't reflect the appropriate responsibilities; If A creates B and gives it to C, then C should have no say in how (or if) it's created. For instance, the Make_Outer code could easily alter the supplied arguments and Make_Inner in any way it chooses. I suppose using an access value has essentially the same problem, as it could simply eschew the supplied value and allocate whatever it wants, but such is life I guess Thank you -sb