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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c80e6f742e73478f X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!i25g2000yqm.googlegroups.com!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: Ensuring postconditions in the face of exceptions Date: Mon, 15 Mar 2010 06:04:14 -0700 (PDT) Organization: http://groups.google.com Message-ID: <8e4c1204-f8a3-4cf5-801e-c6f51eab0ac6@i25g2000yqm.googlegroups.com> References: <820d96c0-5d67-4b8c-8c5b-811ca4f1127e@g26g2000yqn.googlegroups.com> <8990d686-f703-4e9c-91b7-32410289983d@g11g2000yqe.googlegroups.com> <87ljdv56gy.fsf@ludovic-brenta.org> <5f3f45c6-0202-4a67-8517-182afaf7dceb@c16g2000yqd.googlegroups.com> <3782da9f-3f92-455e-ac1c-7cab721fc4df@d2g2000yqa.googlegroups.com> NNTP-Posting-Host: 153.98.68.197 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1268658254 31933 127.0.0.1 (15 Mar 2010 13:04:14 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 15 Mar 2010 13:04:14 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: i25g2000yqm.googlegroups.com; posting-host=153.98.68.197; posting-account=pcLQNgkAAAD9TrXkhkIgiY6-MDtJjIlC User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:9574 Date: 2010-03-15T06:04:14-07:00 List-Id: cjpsimon@gmail.com wrote on comp.lang.ada: > On 15 mar, 10:14, Ludovic Brenta wrote: >> (1) pass Dirty as "access" instead of "in out": works but, as you >> nicely put it, "One of the nice things about Ada over other languages >> is that you generally shouldn't >> have to worry about whether a parameter is copy-by-value or copy-by- >> reference." > >> (2) pass Dirty encapsulated in a limited record: also works but this >> is even worse (IMHO) than "access" because it obscures the purpose of >> the limited record type. I'd have to have 10 lines of comments just to >> explain why there is a limited record type containing a single Boolean >> component. > >> (3) make Dirty part of the object type T: the flag is necessary in >> only one of the places where T is used; also T is serialized in >> several places, so changing it is not a good idea. > >> (4) handle the exception in the caller: there is no longer a central >> place for handling the =A0Dirty flag therefore future maintenance is >> harder. As a side effect, the procedure Refresh loses most of its >> purpose, so might as well disappear. > >> I came up with (5): place both Dirty and the Object to be visited in a >> record type and pass an access value to that record. This is a >> variation of (1); it is still ugly (IMHO) but the record type and the >> access-to-record type already existed so the change to the code base >> was minimal. Since, however, the existing record type contains many >> other things besides the Object and Dirty flag, the procedure Refresh >> receives much more information than it really needs, which might break >> encapsulation. [...] > May be a (6) option is to create a tagged type ? I see this as a variant of (2) and has the same drawbacks. In this case I would have to explain why I use a tagged type that has no primitive operations (the procedure Refresh does not have to be primitive for this type) and no type extensions . -- Ludovic Brenta.