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: Thu, 5 May 2022 20:53:27 -0500 Organization: A noiseless patient Spider Message-ID: References: <0b4ddd38-1f19-44fe-acd9-43a316ec9d29n@googlegroups.com> Injection-Date: Fri, 6 May 2022 01:53:29 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="eeaa7cb0f02c17a27c2e602847c33833"; logging-data="15083"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19n+FXl6q5GScePZFTxpiRXY9jnOKRIAus=" Cancel-Lock: sha1:Ac8Hts9NwYYQ3AbQ5PjaNh/poH8= 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:63815 List-Id: "Dmitry A. Kazakov" wrote in message news:t4vsfi$jtb$1@gioia.aioe.org... > On 2022-05-05 01:49, Randy Brukardt wrote: > >> 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. > > Is a task component a hack? Well so long there is no tagged task types > aggregation is the only way. Task objects look like a cool language feature, but use beyond the simplest patterns will get one into a load of trouble (deadlocks, erroneous use of objects, etc.) Almost all of the correct uses of seen are implementations of the "pool of workers" scheme. But you can do that without any explicit tasks by using the Ada 2022 parallelism features, and that's a lot safer because they include checks against most of the problems. (At least, you can once they're implemented.) Or one could use a library like Brad Moore's to do that (letting it handle the tasks). So, very much like writing your own basic data structures from scratch, this is a feature which is mostly OBE. (Embedded uses are mostly Ravenscar, and that doesn't allow dynamically started tasks in the first place.) > Controlled types are hacks, yes, but there is no alternative. You admit > that all tagged types (and I would say all types) should be controlled = > support user-defined initialization hooks. I don't think I said anything about controlled types being hacks. > Dispatching from Initialize is a double hack, but again, if you need it, > the alternative, client-side manual initialization is way worse. Agree here. > Exception propagation upon initialization? There is no enforceable > exception contracts to fight it. But you don't (or shouldn't) care what happens to an object when an exception is raised during initialization. The program is wrong, it needs to be fixed, end of story. On top of that, the language guarentees that all (controlled) objects that are initialized will get finalized (even when exceptions happen), so there is no possible leakage from a well-designed controlled type. So even in the case of a program that must keep running, resources will not be leaked or corrupted. You can handle the exception and retry. What you can't do is use the object that failed for anything, so the fact that you don't know if it was fully initialized is irrelevant. > So I say, if hacks occur, then because of the language problems, not only > because some lazy programmer does something stupid. You have a strange idea of language problems. (But of course I've known that for a long while; I've written these responses for the benefit of lurkers and the OP, not so much to convince you of anything. :-) Randy.