|
Yes, but unless I am missing something, this isn't a constant. The value of using a constant rather than an initialized variable is that you can't accidently change the value of the constant. While with this solution you, or someone else later, could accidently change the value of one of the days. A somewhat likely example would be something like this. If DayOfWeek.Sunday = Today Or DayOfWeek.Saturday = Today; ItsTheWeekend = *ON; EndIf; Latter someone is changing the program and modifies it to look like this. If DayOfWeek.Sunday = Today; DayOfWeek.Saturday = Today; ItsTheWeekend = *ON; EndIf; Now DayOfWeek.Saturday is no longer 7. Joe Lee >>> Hauser@xxxxxxxxxxxxxxx 12/30/2004 11:22:56 >>> Hi Lee, you can do so, if you replace const through INZ and define the field as 1S 0 or 1P 0: D DayOfWeek DS qualified D Sunday 1S 0 inz(1) D Monday 1S 0 inz(2) D Tuesday 1S 0 inz(3) D Wednesday 1S 0 inz(4) D Thursday 1S 0 inz(5) D Friday 1S 0 inz(6) D Saturday 1S 0 inz(7) *----------------------------------------- /EXEC SQL :Today = DayOfWeek(Current_Date) /END-EXEC /Free Select; When Today = DayOfWeek.Sunday; When Today = DayOfWeek.Monday; ... EndSL; *inLR = *On; /End-Free Birgitta -----Ursprungliche Nachricht----- Von: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]Im Auftrag von Joe Lee Gesendet: Donnerstag, 30. Dezember 2004 20:03 An: rpg400-l@xxxxxxxxxxxx Betreff: Re: Long Constant Names An interesting idea occurred to me while reading this. Would it be possible to add constant qualified data structures? These constants would be used and defined just like a variable qualified data structure. So you would have something like the following. DayOfWeek DS Qualified Const Sunday Const(1) Monday Const(2) Tuesday Const(3) Wednesday Const(4) Thursday Const(5) Friday Const(6) Saturday Const(7) /Free Select; When today = DayOfWeek.Sunday; When today = DayOfWeek.Saturday; EndSl; /End-Free This would help avoid the need to have "long" constant names, at least in the still fixed format D specs, and provide an easy and consistent method of specifying context. Would something like this be a "good" thing? And how hard would it be to implement, Hans? Barbara? Joe Lee >>> antoine.contal@xxxxxxx 12/30/2004 08:12:34 >>> Steve, You're right. In fact, this double semantic load a constant has to bear is the reason I'm talking about constant names specifically, and not variable names in general. Generally speaking, the constant should state both the context (e.g., 'dayofweek', 'ErrMsg') and the value (e.g. 'monday', 'StUpd'). I'd rather put an underscore between the two parts, but if I can't have more than 15 chars, I have to use chars sparingly. Regards. -- Antoine CONTAL something else to keep in mind is that a constant will 99% of the time be one of a set of values. dayofweek_monday dayofweek_tuesday statuscode_active statuscode_held statuscode_deleted It follows that the constant name should always indicate that relationship. What better way is there than the first half of the name is the name of the constant set, the second half is the name of the constant within that set? You dont have to use the underscore if you dont want to. -Steve Les informations contenues dans ce message sont confidentielles et peuvent constituer des informations privilegiees. Si vous n etes pas le destinataire de ce message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d en utiliser tout ou partie. Si vous avez recu ce message par erreur, merci de le supprimer de votre systeme, ainsi que toutes ses copies, et d en avertir immediatement l expediteur par message de retour. Il est impossible de garantir que les communications par messagerie electronique arrivent en temps utile, sont securisees ou denuees de toute erreur ou virus. En consequence, l expediteur n accepte aucune responsabilite du fait des erreurs ou omissions qui pourraient en resulter. --- ----------------------------------------------------- --- The information contained in this e-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. E-mail communications cannot be guaranteed to be timely secure, error or virus-free. The sender does not accept liability for any errors or omissions which arise as a result. $!1$!
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.