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.74.201 with SMTP id w9mr7677319pbv.0.1328581610003; Mon, 06 Feb 2012 18:26:50 -0800 (PST) Path: lh20ni268895pbb.0!nntp.google.com!news2.google.com!postnews.google.com!h6g2000yqk.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 18:19:44 -0800 (PST) Organization: http://groups.google.com Message-ID: <326bcb0a-e37d-4d67-84c2-3d21e3ba3ffe@h6g2000yqk.googlegroups.com> References: <40048c5a-ecf5-43e6-8c76-a294d0c333d1@l14g2000vbe.googlegroups.com> <45c75d2a-02b4-40b2-b69b-04c6bf7a47a5@t2g2000yqk.googlegroups.com> <57a267ec-b901-401e-b415-ca6d9cf47616@d15g2000yqg.googlegroups.com> NNTP-Posting-Host: 24.218.138.255 Mime-Version: 1.0 X-Trace: posting.google.com 1328581609 3638 127.0.0.1 (7 Feb 2012 02:26:49 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 7 Feb 2012 02:26:49 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: h6g2000yqk.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-06T18:19:44-08:00 List-Id: On Feb 6, 7:53=A0pm, Adam Beneschan wrote: > On Feb 6, 4:27=A0pm, Simon Belmont wrote: > > > On Feb 6, 7:03=A0pm, Adam Beneschan wrote: > > > > (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 privat= e > > > part). > > > It is basically this, and I really have no objection in using the > > access type. =A0But since Ada can do it for a public type, I was just > > interested if there was some sort of official way for a private type > > (which would avoid the necessary evils of lifetime control, > > accessibility, etc.) > > For a public type, the program has the information that an Outer > contains an Inner (assuming you don't use access types). =A0Thus it can > create the Outer and its Inner at the same time, using a single > aggregate. =A0You can't create an Inner first and then create an Outer > later, even if it's a public type. > > Since this information is private, the body of your package is the > only one that knows that an Outer contains an Inner; therefore, it's > the body of your package that has to create an Outer and an Inner at > the same time. =A0Based on that, I don't think your objection to > Shark8's solution makes sense. > > I'm assuming here that you really want an Outer to *contain* an Inner, > rather than an Outer containing a *reference* to an Inner. =A0And I mean > this in terms of an abstract description of your problem, not in terms > of using an access type as your mechanism for implementing all this. > But since you're now saying that an Outer actually *refers* to an > Inner, in your problem description, I guess the whole discussion may > be moot. =A0You really are going to have to decide what you want. =A0Is a= n > Inner a separate kind of object that you want package users to be able > to have independently of an Outer? =A0Does it make sense for the program > to declare a standalone object of type Inner and use it? =A0Or does an > Inner make sense only as part of the larger Outer object? > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Adam >From a purely abstract view, then yes, one record 'has a' other, such as a 'picture' or 'sound' or 'employee' type might contain a limited file type within that it uses to read and write its data from disk. They would have the same lifetime, and have a one-to-one correspondance. The issue is that I don't want to couple the outer type to the concrete type of the inner; suppose Inner is really Inner'Class, and Outer should remain abstract enough to work given any concrete type upon initializtion (perhaps File could be any number of concrete types that perform various encryption/compression, etc). A 'normal' object cannot be passed in due to the aforementioned problem, the arguments cannot be forwarded over because the Make_Inner would be specific to one concrete type, and access values seem unnecessary for this situation. I suppose the 'right' thing to do would be to create factory-type objects so that all Make_Outer has to do is call some hypothetical Create function of the argument, but I didn't want to waste my time if there was a method involving less typing. Thank you again -sb