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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: jsa@alexandria.organon.com (Jon S Anthony) Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/08/12 Message-ID: #1/1 X-Deja-AN: 263893970 References: <33E9ADE9.4709@flash.net> Distribution: world Organization: PSINet Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-08-12T00:00:00+00:00 List-Id: In article donh@syd.csa.com.au (Don Harrison) writes: > it can be expected to do a better job of it. If Ada protected types allow > the designer to explicitly leave objects unlocked (which doesn't appear to > be supported by the Ada95 Rationale), then they are more permissive but > in a detrimental way, IMO. You're not twigging this stuff. The objects can be unlocked for _read_ access, but never for any update access. Now you can make a value judgement that this is worthless or misguided, but that's different. > :can requeue requests, > > IMO, the situations in which you would use "requeue" are better handled by > designing differently - perhaps by using an additional class. If anything, > "requeue" probably encourages poor design. Requeue is specifically there to eliminate in principle any timing errors. The way this works is somewhat subtle, so maybe you are not twigging this either. > simulating the surrounding environment. Then, any assertions > assuming Ariane 4 inputs would be violated (as would the Ada > constraint_error). In general, the extra checking afforded by DBC > would mean more bugs would be identified than if it wasn't > used. (Yes, I know there is no difference wrt the one that caused > the failure.) The problem with this is the simple observation of "why would the assertions be there in the first place?" After all, in the particular case at hand, they were _intentionally_ removed. And with perfectly sound engineering principles in mind. Assertions in the code _cannot_ capture the constraints presumed for the context of use. This has to come from somewhere else (external documentation, "instructions", "warrenty notes", whatever.) The odd thing here is that this point should be "blindingly obvious", to use one of your phrases. > :Any time someone says something is obvious, without any evidence or > :argument to support it, I pretty much assume that the point is ceded. > > No, it just means I'm just getting impatient. :( Same here - In SPADES. /Jon -- Jon Anthony OMI, Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari