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: Sat, 7 May 2022 21:32:22 -0500 Organization: A noiseless patient Spider Message-ID: References: <0b4ddd38-1f19-44fe-acd9-43a316ec9d29n@googlegroups.com> Injection-Date: Sun, 8 May 2022 02:32:24 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="1295a80121bac150198daa6d2ac318e5"; logging-data="14566"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18+UlntXWDPyb7vfd20YTTFIHRSo7zhFo4=" Cancel-Lock: sha1:8TpqryN8vh/TnZT8oflANsHqbEI= 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:63825 List-Id: "Dmitry A. Kazakov" wrote in message news:t5619r$10bc$1@gioia.aioe.org... > On 2022-05-07 05:26, Randy Brukardt wrote: >> "Dmitry A. Kazakov" wrote in message >> news:t52nd4$vj2$1@gioia.aioe.org... > >>> Because the task type is not composable. >> >> Irrelevant. A task can only be safe if it never interacts with no other >> objects outside of itself. > > Not when other objects are tasks, protected objects, active objects, > atomic objects. That's a common fallacy. Such objects are safe only if there is exactly one in your system. If there is more than one, various forms of failure are possible even if everything is supposely safe by itself. To make them fully safe, you have to have strong access ordering (for instance, the onion skin model), which no programming language and probably no static tool can enforce. (Proof of safety requires verification that no possible program flow can cause a race condition.) ... >> No, I'm just pointing out that retrying is safe by the language. You seem >> to >> think it is not. Servers need such guarentees to avoid denial-of-service >> issues. > > No, the contradiction is that you claim that safe construction is > fundamentally impossible and yet concede that it is safe nonetheless. "Construction" is safe, always has been (it's not a user level thing anyway). Initialization is safe unless you use hacks to make it unsafe (but that's sadly common). But the only initialization one should be depending upon is quite simple. ... > Because the language lacks obvious abstractions like user-defined > discriminants. Otherwise I see no logical reason why: > > F : File_Type ("My_Ada_file.adb"); > > should not work. It does "work", but such designs put major restrictions on your clients. A common way my programs are structured is something like: declare Output_File : Some_File_Type; begin Create_or_Open_Output (Output_File); Write_Output (Output_File, Data); ... Close_Output (Output_File); end; You can't use such a structure with your design, because you can't pass in the unopened file object to open it appropriately (which can take multiple attempts depending upon options, file existence, and the like). Another design would hide the file object in the package body rather than passing it as a parameter. But you can't do that either, since you can't declare the object at library-level in this design (you haven't yet processed the program's command line, so you don't know what file to open). You have to resort to using access types and allocators to get the right effect. But any ADT design that requires that forces memory management on the user (it is necessarily incompatible with letting the language or libraries like the containers doing the memory management). Such designs are purely evil. :-) Discriminants are only useful for memory management (to size arrays, to make components conditional). Other uses are purely mistakes. >> Besides forcing virtually all objects to be allocated (since most >> objects have to live longer than a single subprogram), it doesn't handle >> cases where outside forces close the object (common in file systems, >> GUIs, >> etc.). You still end up with those error states, you've just complicated >> creating an object for no benefit at all. > > I simplified creating the object by removing states when the object is > unusable for no other reason than language design. Cases when the file can > be unreadable because of I/O errors have nothing to do with the case when > the programmer did not open it. There is no difference between the state of an object before it is opened and the one it is in after it is closed. (And these aren't just error cases, as noted by the Windows example.) >> We initially trying designing Claw Window objects that way, but one had >> to >> handle the case where the user clicks the 'X' (close button) while a >> routine >> is working on the window. Windows closes the window almost immediately, >> and >> the GUI library has to deal with the consequences. > > Windows sends WM_CLOSE first. Sure, but the only thing you can do at that point is make the object invalid. You certainly can't make objects that exist and possibly are actively being used disappear! And you can't just raise an exception, you may not even be operating on that window object at the time. >> There's little point in obsessing about designs that only work in >> academic >> exercises. Ada tries too hard already to accomadate designs like yours. > > On the contrary, it is a very practical software design problem to reduce > error sources as much as possible. An imaginary reduction of errors, since you have the same states that occur in other usage scenarios. And for that, you are preventing the object from being managed by the compiler, or even usefully composed. Stupid. Randy.