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: border1.nntp.ams.giganews.com!nntp.giganews.com!feeder.erje.net!eu.feeder.erje.net!weretis.net!feeder4.news.weretis.net!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: The future of Spark . Spark 2014 : a wreckage Date: Sat, 20 Jul 2013 00:32:44 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: 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> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1374298365 1343 69.95.181.76 (20 Jul 2013 05:32:45 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 20 Jul 2013 05:32:45 +0000 (UTC) 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: number.nntp.dca.giganews.com comp.lang.ada:182601 Date: 2013-07-20T00:32:44-05:00 List-Id: "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. (Imagine copying data from one file to another with a transformation: if one of the files has an I/O error, you no longer can clean up the other one (you might be able to use nesting to get it to work one way, but not either way). In any case, this seems like solving a non-problem, as closing files and the like is trivially handled by finalization. (I don't much care about people who refuse to use the tools they're given.) 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. 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. So, I don't think it works outside of the simplest cases. Randy.