In a message dated 7/25/2005 7:25:53 AM Pacific Daylight Time, [EMAIL PROTECTED] writes:
> I started to use this syntax (ELSE ID = @AM) several years ago. It > originated, I think, from the "Advanced Pick Programming" book, circa > 1990. The theory went that if you used a separate variable, usually EOF, > in the ELSE clause, the variable would get forced out of memory and would > have to be read back in from disk for each subsequent READNEXT. The > attribute mark, on the other hand, was usually equated. On the systems of > that time, this resulted in a fairly big improvement in larger programs. > In small programs, where everything fit into memory, this would not > provide any benefit. There are a few problems with this theory. @AM is only a typical component of U2 systems and so would not, most likely, have been included in the Advanced Pick Programming book that was writen using generic code that would run acrost all platforms. I'll have to check my copy later today as I'm not at my office just now. The more important problem is that the variables are all mapped into a contiguous workspace that is referenced so continously that it's highly unlikely it would ever get paged from memory, while your process is running, except perhaps on systems that were so woefully underbuilt that paging BASIC variables would be the least of your problems. The main argument against it, is that it's not as clear as using True and False, which are nearly universally understood concepts in programming. Coding simply, means less learning curve for your new programmers. I have headed a few programming departments, and in my opinion, in the contest between getting programmers up-to-speed, and getting the machine to run as efficient as possible; the programmers have to win every time. That's my three cents. Will Johnson ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
