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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.albasani.net!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: derived formal types and known discriminants Date: Mon, 3 Jul 2017 21:29:15 -0500 Organization: JSA Research & Innovation Message-ID: References: <82a59ee9-8d55-4c73-9daf-e9f7d9ab8a8f@googlegroups.com> Injection-Date: Tue, 4 Jul 2017 02:29:16 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="16644"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:47274 Date: 2017-07-03T21:29:15-05:00 List-Id: wrote in message news:a1bd4695-00ff-49a8-a07a-84ebdb043202@googlegroups.com... On Friday, June 30, 2017 at 2:10:01 PM UTC-4, Randy Brukardt wrote: >> Sure, but they're very inflexible in that usage (as bad or worse than the >> original unconstrained types). So I tend to view these as an either/or >> proposition: untagged, mutable types with discriminants, or tagged types >> without discriminants. Again, YMMV. >At the risk of having some of the other thread's shade thrown in here, >aren't >tagged discriminated records the de facto way of doing initialization? >That is, >extending a Controlled type and then using discriminants in place of ctor >arguments? I've heard of people trying to use that sort of thing, but I find it too inflexible (in that you have to declare an object at exactly the right place). Thus most of my types default-initialize to an "invalid" state, and there is one or more "Create" or "Open" routines to make a usable version. A bit more complicated, but it allows the initialization to occur anywhere (not necessarily where the object is declared, which usually is picked to give the proper lifetime for the object - that is, the destruction point) and the initialization can have arbitrary parameters. You do need a check (or precondition) for validity for most operations, but that should be optimizable (if written as a precondition with an appropriate stable property [in Ada 202x]). So it shouldn't cost much if anything at runtime. This after all is the model of file objects in Ada 83, and it works well for them and many other things. Randy.