From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,XPRIO autolearn=no autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Discriminants or Constructor Function for Limited Types Date: Wed, 4 May 2022 18:49:51 -0500 Organization: A noiseless patient Spider Message-ID: References: <0b4ddd38-1f19-44fe-acd9-43a316ec9d29n@googlegroups.com> Injection-Date: Wed, 4 May 2022 23:49:52 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="31dd1ecc44efe8612e0c7b29d7411732"; logging-data="22027"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18PhsuODhHsbJczun3v/ObHxZIWiEaH8YI=" Cancel-Lock: sha1:WpxtwcdT3fST+rOqCQj0N6I6PHs= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-RFC2646: Format=Flowed; Response X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-Priority: 3 X-MSMail-Priority: Normal Xref: reader02.eternal-september.org comp.lang.ada:63812 List-Id: "Dmitry A. Kazakov" wrote in message news:t4ti4a$s1u$1@gioia.aioe.org... > On 2022-05-04 11:02, R R wrote: >> There are two ways (to my knowledge) how to initialize objects of limited >> types. Either the limited type has some discriminants >> >> type DLT (Width, Length : Positive) is tagged limited private; >> Obj : DLT (3, 5); >> >> or I can provide a constructor function that takes corresponding >> parameters >> >> type LT (<>) is tagged limited private; >> function Make (Width, Length : Positive) return LT; >> Obj : LT := Make (3, 5); >> >> Do you recommend one way over the other? Why? Is it possible to combine >> both methods (discriminants plus constructor)? > > Two more ways are allocators and limited aggregates. > > There is no good way to safely initialize a limited object because Ada > lacks proper constructors and because the initialization model is > inherently unsafe with regard or exceptions, task components, > self-referential discriminants (AKA Rosen's trick). > > But there are numerous hacks and workarounds depending on the objective. Those cases that you worry are "unsafe" seem to me to only occur because of "hacks and workarounds". There's no good reason to do any of those things intentionally unless you are using a "hack" to do something dubious in the first place. To answer the OPs question, the reason to prefer one initialization scheme over another mainly comes down to how you are going to use the type. If you don't expect it to be composed with other types, use whatever is comfortable (I ususally use a procedute in such cases, and have the type self-initialize to "invalid" so it can't be used until a call is made). If you need to compose the type with other similar types, it helps to use the same initialization mechanism for all (that is, it's easiest to initialize discriminants with other enclosing discriminants, and initialize via a function from another function). Also note that you can combine discriminants with the (automatically called) controlled type procedure Initialize to do more complex initialization based on the discriminants. My preference is to make almost all new types controlled, not everyone agrees with that. Randy.