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: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public From: Tres Seaver Subject: Re: Software landmines (loops) Date: 1998/09/02 Message-ID: <35EDB334.B65F7D81@palladion.com>#1/1 X-Deja-AN: 387299089 Content-Transfer-Encoding: 7bit Sender: news@ect.enron.com (news Admin) X-Nntp-Posting-Host: 172.16.67.71 References: <902934874.2099.0.nnrp-10.c246a717@news.demon.co.uk> <6r1glm$bvh$1@nnrp1.dejanews.com> <6r9f8h$jtm$1@nnrp1.dejanews.com> <6renh8$ga7$1@nnrp1.dejanews.com> <6rf59b$2ud$1@nnrp1.dejanews.com> <6rfra4$rul$1@nnrp1.dejanews.com> <35DBDD24.D003404D@calfp.co.uk> <6sbuod$fra$1@hirame.wwa.com> <35f51e53.48044143@ <904556531.666222@miso.it.uq.edu.au> <6sf87j$47n$1@hirame.wwa.com> <6sfrok$h3i$1@hirame.wwa.com> Content-Type: text/plain; charset=us-ascii Organization: Palladion Software Mime-Version: 1.0 Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-02T00:00:00+00:00 List-Id: Robert Martin wrote: > > Matthew Heaney wrote in message ... > >"Robert Martin" writes: > > > >> >Would the implementation be better by not using multiple returns? > >> > >> Yes. Imagine that you had to change the function to make it thread safe; > >> and that the way to do that was to sieze and release a mutex while the > >> function was executing. As written you would have to add the release in > >> three separate places. But if you had avoided the multiple returns, you > >> would have had a single release. > > > >Well... The proper way to use a mutex is to wrap it in a controlled > >type, so that release is called automatically as a result of subprogram > >exit, no matter what the reason. (Controlled types in Ada have > >operations that are roughly analagous to constructors and deconstructors > >in C++.) > > In a language that supports such things, using controlled types is *a* way > (not necessarily the "proper" way). (it happens to be the way that I choose > in many cases). But this has nothing really to do with the issue at hand. > Yes, it may be feasible to put some resource management code into a > controlled type and avoid the issues of maintenance that I raised earlier; > but that doesn't eliminate the problem of structure. In the end, if you can > make the structure of the software solve a problem, that is better than > using a special language feature to do it. I find it interesting to read all the "single entry / exit" argument in light of the prolifieration of exception-based mechanisms. Exceptions have all of the disadvantages of multiple returns, with the added problem of invisibility. Adjusting one's style to remain robust in the face of exceptions automagically makes for robustness in the presence of multiple returns, it would seem to me. -- Tres Seaver tseaver@palladion.com Palladion Software http://www.palladion.com Houston, Texas, USA Vox: (713) 523-6582