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,efc9f994d31d0d5e X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!s8g2000prg.googlegroups.com!not-for-mail From: Eric Hughes Newsgroups: comp.lang.ada Subject: Re: Limited initialization for non-limited types Date: Fri, 28 Mar 2008 08:25:08 -0700 (PDT) Organization: http://groups.google.com Message-ID: <8ce4085b-08c9-4f3b-9909-3a68b8832194@s8g2000prg.googlegroups.com> References: <05336885-5b45-4b2d-b27c-733c2002ca58@s13g2000prd.googlegroups.com> NNTP-Posting-Host: 166.70.57.218 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1206717908 11667 127.0.0.1 (28 Mar 2008 15:25:08 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 28 Mar 2008 15:25:08 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: s8g2000prg.googlegroups.com; posting-host=166.70.57.218; posting-account=5RIiTwoAAACt_Eu87gmPAJMoMTeMz-rn User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:20615 Date: 2008-03-28T08:25:08-07:00 List-Id: On Mar 28, 12:56 am, "Randy Brukardt" wrote: > Moreover, I was one of those that was not originally convinced that a > function makes an adequate constructor. But I wasn't able to convince > others, and eventually you have to compromise and move on. I haven't been able to find a smoking-gun example that you can't work around with existing syntax. I'm keeping my eye out for one, though. The best I know of now is that it's problematic to eliminate default- value initialization at compile-time (easy to do at run-time). This is useful only for types where no default value is sensible (such as not-null-access types) and it's only relevant within a private implementation (by eliminating public visibility of components). On the other hand, it's a missing aid to an implementer--in the same class of aid as "type Index is new Integer"--not strictly necessary, but a felicity of the language. As to the technical part of the idea, I'll propose "::=" as token for the initialization operator. As to the build-in-place requirement, it seems part of a larger idea I've been mulling over, which is a more general representation facility. As an example, in an ideal world, I'd like to have the Convention, Import, and Export pragmas become ordinary code. The core theory is in Tony Hoare's paper "Proof of Correctness of Data Representations" (1972). Its essence is a formal way of mapping between two different representations with equivalent ultimate effect. The largest visible change to Ada (or to any other language) would be to make identifiers both for representation languages (name spaces) and for representation conventions (maps between them). I doubt this will happen any time soon, though, since it seems a solid research project to develop the necessary pragmatic theory to apply this to a real language. > Code that requires a > particular sequence of calls is wrong (even though it might work). Well, I'm not looking for any particular sequence of calls, really. My immediate application is to verify invariants in run-time by trapping on particular events (right now it's those of Controlled). > I still think that your entire approach is wrong. I'd probably either try > something using a mixin generic, or more likely simply with a bit debugging > code built into the base class. I looked at initialization first because it's more widely applicable outside of my immediate need, for which I think type discriminants may work. A discriminant whose access_definition is a handle to ordinary record seems to allow most everything I can think I need soon. [re: private components] > It would take quite a bit of thought to ensure that such > problems don't lurk here. Granted. Eric