Simply stated, Larry said it for me! I agree! David
David Blocker [EMAIL PROTECTED] 781-784-1919 Fax: 781-784-1860 Cell: 339-206-0261 ----- Original Message ----- From: "Lawrence Lustig" <[EMAIL PROTECTED]> To: "RBG7-L Mailing List" <[email protected]> Sent: Monday, February 07, 2005 11:24 AM Subject: [RBG7-L] - Re: Fetch command > << > But David and Larry ("There's no extra checking. In David's method,the WHILE > loop becomes an > infinite loop"), doesn't the WHILE loop always have to check the > condition,whether it's a moving target like SQLCODE <> 100 or an infinite > looplike WHILE 1 = 1. > >> > > I think we're getting confused on the difference between the processing of the > WHILE condition, and the programming logic. > > Yes, the WHILE loop condition may need to get processed at each iteration. A > compiled language would optimize out an always-true condition. R:Base probably > does not, but that's okay, the processing time is insignificant. > > The more important issues to my mind are that the code be clear and > maintainable and, to the extent possible, the same logic is NEVER duplicated in > the code. The first issue mandates for a WHILE loop instead of GOTO / LABEL > processing, the second condition mandates that both the FETCH logic and > end-of-loop logic appear only once in the program. When I said "there's no > extra checking" what I should have said is "the checking logic for ending the > WHILE loop appears only once." > > There was a time when I think a lot of R:Base programmers ripped out all their > WHILE loops in favor of GOTO / LABEL structures because of perceived memory > leaks and other problems with this programming structure. For my part, I never > observed the problem with WHILE loops in any stable version of R:Base -- any > problems I did encounter always turned out to have any solution, usually > correcting some problem with my code. > > There is a saying in programming -- "Premature optimization is the root of all > evil". In other words, algorithms should be implemented clearly and cleanly > first, and only then optimized if they are not sufficiently fast. In that > vein, I prefer David's method because it is the clearest (at least to me) and > also the easiest to maintain and is always fast enough to get the job done. > -- > Larry > >
