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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: The future of Spark . Spark 2014 : a wreckage Date: Sat, 20 Jul 2013 11:06:32 +0200 Organization: cbb software GmbH Message-ID: <1fubu2qnlm6q.hfwlyear921e.dlg@40tude.net> References: <1vc73wjwkqmnl$.gx86xaqy60u4$.dlg@40tude.net> <6pqhcwi0wuop.15v6h3g7gkto4.dlg@40tude.net> <1s6sw93u97355$.1n0205ucj6251.dlg@40tude.net> <1lhsyg46iz9jj.8jrvydqxt8l6.dlg@40tude.net> <1d4tuwlfdnz2j$.18l68s96x3vjj.dlg@40tude.net> <1rjye7dyn3vgk.66fbcca9y4zd.dlg@40tude.net> <1awbjaens2vca$.1asmpnthmmycl.dlg@40tude.net> <17i525dc26pat$.1octlzd41c8zm.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: R0SnWoufDrgXLosLSQbuFw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:16449 Date: 2013-07-20T11:06:32+02:00 List-Id: On Sat, 20 Jul 2013 00:32:44 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:w30s4q4tdrue$.1q2ek7n0im2ba$.dlg@40tude.net... >> On Thu, 18 Jul 2013 23:32:57 -0500, Randy Brukardt wrote: >> >>>> It won't be any more complex than it is when handling exceptions >>>> propagating out of Open. In fact it will be much simpler because you >>>> forgot the issue of closing the file on subsequent errors. >>> >>> I've never had the slightest "issue" with closing the file at the end. >>> And >>> certainly, there aren't "subsequent errors", because either the file gets >>> opened eventually, or the whole routine is aborted (usually, the entire >>> program is halted at the point, since failure to be able to write >>> results -- >>> no one needs to calculate results if you can't save them). >> >> I meant I/O errors and more elaborated cases like sockets. If you open a >> socket file you should bind it, set options which may fail as well. Code >> that does not use controlled wrappers look very ugly. >> >> It is *always* a much better design when the object maintains a state >> invariant (e.g. file is open). Provability of such code is a nice >> byproduct. > > But isn't that impossible, practically? If the USB drive is unplugged, it's > impossible to get to the file. Same with sockets. If you mean that it's > required to propagate an exception out of scope so that it's impossible to > access a file object that's not open, that's going to make a lot of trouble > because of overlapping file lifetimes. I think it is a consequence of your approach that leads to conflating states of a file, of its descriptor, of the Ada's proxy to that descriptor and all OSI levels from top to the bottom into one big mess. Yes, if you do that it will never be possible to check. My approach is to identify states which can be statically determined and make them invariant. A file being opened or a socket created is such a state. Non-opened file has no use. Similarly a bound socket is an invariant for another type, and a connected socket is for yet another. When a connection gets closed by the peer pending I/O should propagate an I/O error exception for opened-bound-connected socket. This exception has nothing to do with attempting to read fron a non-existing file description. Because the latter is a bug to me, which shall be prevented statically. > Anyway, I think the problem with your scheme is on the initialization end. > Initialization (as you seemed to acknowledge above) is just too complex for > many of these objects to do it as part of the object declaration. My answer is that even talking about complexity is breaking abstraction. It is irrelevant how complex an opaque operation is. > Indeed, we (briefly) tried to use a scheme like the one you are suggesting > for the Claw packages. We immediately ran into problems with too many > parameters (especially for discriminants). And there were further problems > with the interrelationships between the objects; we would have had to > extensively use access types, which would have greatly compromised the > ease-of-use and especially the bulletproof-ness goals that we had for Claw. These problems are mostly language problems, namely lack of proper constructors and encapsulation of initialization/finalization. Your and others opposition to fixing constructors in Ada is to large extent based on flawed design patterns like you described. > So, I don't think it works outside of the simplest cases. On the contrary, it is the flawed "first construct then initialize" pattern, which is simple only on paper. In practice it is becomes a huge maintenance and testing problem because it shoulders all the burden on the clients => distributed overhead. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de