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.9 required=5.0 tests=BAYES_00 autolearn=ham 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.222.71 with SMTP id qk7mr12437368pbc.1.1328573005856; Mon, 06 Feb 2012 16:03:25 -0800 (PST) Path: lh20ni268518pbb.0!nntp.google.com!news2.google.com!postnews.google.com!t2g2000yqk.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Building limited types through nested creator functions Date: Mon, 6 Feb 2012 16:03:25 -0800 (PST) Organization: http://groups.google.com Message-ID: <45c75d2a-02b4-40b2-b69b-04c6bf7a47a5@t2g2000yqk.googlegroups.com> References: <40048c5a-ecf5-43e6-8c76-a294d0c333d1@l14g2000vbe.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 X-Trace: posting.google.com 1328573005 13253 127.0.0.1 (7 Feb 2012 00:03:25 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 7 Feb 2012 00:03:25 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: t2g2000yqk.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ 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; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C),gzip(gfe) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-02-06T16:03:25-08:00 List-Id: On Feb 5, 2: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 an > 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. I think you have to decide: is an "Inner" an actual object that you want to prevent copying of for some reason, or is it a collection of components that you want to use to initialize an "Outer"? Something seems wrong with your paradigm here. (1) If an Outer actually contains an Inner, then you're trying to set things up so that a program that uses this package will create an Inner, and then create an Outer that contains a copy of the Inner. But this contradicts the idea that Inner should be a limited type. Limited types are for objects that you don't want to make copies of. (2) If you want users of the package to create an Inner, and then create an Outer that *refers* to that same Inner (without making a copy), then you shouldn't object to using access types (in the private part). (3) If you want the ability for users to create an Outer that contains some of the interesting data from an Inner, then maybe an Outer shouldn't be thought of as containing an "Inner" as a component. In that case, you may want to declare a new record type Inner_Data that includes interesting information from an Inner, and make your Outer contain this as a component instead of Inner. (4) If you want Outer and/or Inner to refer to objects that can be copied, they shouldn't be "limited"--and note that for untagged types, you can declare a type to be limited in the visible part, and nonlimited in the private part, so that you can do assignments in your package body, but users of the package still can't make copies. I don't know which one is the case without knowing more about the actual application that you're trying to write. But in any event, something seems wrong with the design. -- Adam