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,fc52c633190162e0 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!newshub.sdsu.edu!newscon04.news.prodigy.net!prodigy.net!newsdst01.news.prodigy.net!prodigy.com!postmaster.news.prodigy.com!newssvr22.news.prodigy.net.POSTED!4988f22a!not-for-mail From: Newsgroups: comp.lang.ada References: <1172144043.746296.44680@m58g2000cwm.googlegroups.com> <1172161751.573558.24140@h3g2000cwc.googlegroups.com> <546qkhF1tr7dtU1@mid.individual.net> <5ZULh.48$YL5.40@newssvr29.news.prodigy.net> <4eeMh.16400$bb1.2557@newssvr17.news.prodigy.net> Subject: Re: Use of declare blocks X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RFC2646: Format=Flowed; Original Message-ID: NNTP-Posting-Host: 70.134.112.39 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr22.news.prodigy.net 1174582727 ST000 70.134.112.39 (Thu, 22 Mar 2007 12:58:47 EDT) NNTP-Posting-Date: Thu, 22 Mar 2007 12:58:47 EDT Organization: AT&T http://yahoo.sbc.com X-UserInfo1: SCSGW^WETZSMB_DX]BCBNWX@RJ_XPDLMN@GZ_GYO^BTBTSUBYFWEAE[YJLYPIWKHTFCMZKVMB^[Z^DOBRVVMOSPFHNSYXVDIE@X\BUC@GTSX@DL^GKFFHQCCE\G[JJBMYDYIJCZM@AY]GNGPJD]YNNW\GSX^GSCKHA[]@CCB\[@LATPD\L@J\\PF]VR[QPJN Date: Thu, 22 Mar 2007 09:59:05 -0800 Xref: g2news1.google.com comp.lang.ada:14598 Date: 2007-03-22T09:59:05-08:00 List-Id: When I say they "ought to be used minimally," I am speaking from the experience of seeing programmers at former client sites who used them maximally. There are several problems with declare blocks. 1) They often lead to ad hoc designs, 2) They often become long passages of code extending over many pages, 3) They look like procedures It is quite easy in Ada to promote a declare block to a subprogram and in-line it. This often has the effect of inspiring the designer of that declare block to think it through a bit more carefully. Sometimes it results in improving the overall design of the final set of programs. I recall one aerospace user of Ada in California where the programmers sprinkled declare blocks all through their code, almost in a stream-of-consciousness fashion. When used by someone such as Randy, a programmer who uses every construct with care and intelligence, the declare block is not a primay design structure but a way of bringing subtle refinement to an already good design. When used in place of careful planning, as it often is, or as an afterthought, as it often is, the declare block can do more to muddle the understanding of a piece of code than to improve it. That being said, Ada blocks, including declare blocks, do have the virtue that they are well-bounded, can be named, are rigorous in their obedience to the underlying rules of the language, and useful in those rare circumstances where they make sense. Finally. I have noticed over the past forty + years of being a programmer that the people who make up rules for programmers tend to be people who no longer write programs, or, in some cases, never have written any programs. I would not want anyone to think I am making up a rule about declare blocks. I do maintain my view that they need to be used sparingly, and sometimes promoted to in-lined procedures -- but this is not a rule. Richard Riehle ================================================ "Randy Brukardt" wrote in message news:ets49o$m8j$1@jacob-sparre.dk... > wrote in message > news:4eeMh.16400$bb1.2557@newssvr17.news.prodigy.net... > ... >>Units >> in Ada, including declare blocks (which ought to be used minimally) >> have the option of being named. > > While I generally agree with Richard, I certainly don't agree on the "ought > to be used minimally" here. > > I use declare blocks extensively to reduce the scope of temporary variables > in subprograms. They're especially important when the object exists just to > take an unused out parameter, because they greatly reduce the need to come > up with names for the objects. I often have code like: > > declare > Junk : Index; > begin > Insert_Something (..., Result => Junk); > end; > > where the result isn't needed by the following code. (Sure, one could argue > that the underlying library should be improved to avoid the need for this, > but that isn't always possible and in any case changes to widely used > specifications shouldn't be made lightly. And this is just one example, any > sort of temporary has these sorts of requirements.) > > The advantage is that if in the future you find that you no longer need the > temporary, you can remove it without heavy code analysis: it is used only in > the one place and there is no worries that it might be reused, or have a > side-effect, or the like. > > Randy. > > > >