|
> ok, this is the place I usually start getting lost when trying to maintain > this new stuff. What are you doing, and what is the advantage? Are these > added lines of code just to prevent having to define a field as *HMS in a > prototype? I guess this is the result of topic drift. Here's where I was going with the symbolic constants: there was a suggestion, deprecated by Barbara, to use a parameter to identify whether the sleep was 'for' or 'til' -- I think it may have been you who suggested it, Booth. Let's pretend for a second that we are still using that method. If you simply use string literals, there is a danger that the wrong string will get passed into the procedure. For example, after several hours of coding, I do something daft like pass 'ti1' instead of 'til' -- note that I accidentally substituted the digit 'one' for the lowercase 'l'. The results of this are unpredictable; they depend on how the procedure handles the argument. If, for example, it uses the logic if type = 'til' (do something) else (do something else) endif you will get the 'for' logic unexpectedly. The answer I use is to code symbolic constants, which by convention in many languages are represented by all uppercase variable names. The examples I gave were FOR and UNTIL, to which I assigned constant values of 0 and 1, respectively. Note that these are now numeric variables. The procedure uses these constants exclusively: if type = UNTIL which is exactly equivalent to if type = 1 only clearer. The calling program uses the same constants, and everybody is happy. We even get some compile-time checking: if I mis-spell UNTIL, the compiler will complain about an undeclared variable. The question remains, how do we make sure that the caller and the callee use the same constant names to mean the same thing? This is where the /COPY member comes in. The source containing the procedure includes the /COPY, in order to include the prototype for the procedure. The calling program uses the same /COPY member. This makes it the ideal place to store the constants. Again, Barbara correctly pointed out that it was more appropriate to use two procedures in this case. There are other situations where this is not so, and for these I would use symbolic constants. Did all this help, or just confuse the issue further? -- Paul +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.