|
Hello Scott, You wrote: >Sigh... not the "*INKC vs *IN03" holy war, again. And I should know better than to consider responding ... >a) *INKx is simple and to the point. They are not simple and to the point at all. They involve a mental translation that is entirely unnecessary. >b) *IN01, *IN02... Yes, it's easy to figure out what these are when > things are working, but there's an added step when things aren't > working of verifying that *in01 is used for F1 and only for F1, > and the same for *IN02-*IN24. Is that difficult? No. But it's > one step of complication above *INKx, and provides very little > benefit. (Unless the idea of C being the 3rd letter of the > alphabet confuses you) It's not the first few that bother me. It's the last few. No-one (even those who think they can) can tell me what *INKI or *INKP is quickly enough to avoid the mental translation. The other argument you raise regarding *INnn being used elsewhere is simply specious. >c) AID bytes. This is EASILY more complicated than the two steps > above combined. It works great. And it lets you use nicely > named words like "KEY_F1" to represent your function keys. > But... it's a GREAT DEAL more complicated than the indicator > approach, and the end result is EXACTLY THE SAME. What ever > happened to "K.I.S.S."? It's only more complex in the initial setup. Everything can, and should, be hidden away in copy members. Copy members can hold the key definitions, the feedback data structure, etc. The advantage is directly readable and intuitive code. *INKx is not intuitive -- see response to a) above. >Frankly, Simon, I find your tone frustrating. Oh dear, how sad, never mind! Although I think you have a different word in mind -- tone cannot be frustrating. >Apparently in order for my programming standard to be "decent" it has to >follow your flawed logic. Aside from the fact that my logic is not flawed, I see nothing else wrong with the above sentence. >I'm not an "ancient" RPG programmer. I'm way beyond the curve when it >comes to modern coding. Activation groups are 2nd nature to me. I use >APIs every day. I do network coding. Stream file coding. My shop, >unlike most, has been coding RPG IV since 1996. I'm NOT a dinosaur. Not a dinosaur? Really? Yet you think *INKx is obvious, self-documenting, and simple? Res ipsa loquitur! 1996? Hmm, I've been doing RPG IV since at least '95 and ILE since '93. Everything else in your list is standard fare to me too so don't start a pissing contest. >(Though, frankly, I think "out of date" whenever I see a CASEQ in a >program, or code that's in all caps, or subroutine names that are >unnecessarily abbreviated to 6 chars long.) I did point out that the example code I used for the C-specs was RPG III hence the six character names and uppercase variables, I guess you missed that statement. I do actually prefer RPG op-codes in uppercase but don't mind if someone else chooses to use lowercase or mixed case -- it doesn't affect the legibility. The CAS construct is still useful for handling function keys and subroutines still have their place -- not everything should be replaced by procedures. >I use the *INKx indicators because they are THE MOST INTUITIVE OF THE >OPTIONS AVAILABLE, not because I'm ancient. I just dont see how you >could POSSIBLY be confused by the *INKx indicators. They are not intuitive regardless of what you might think. Supposedly rational people manage to harbour both logic and faith within the same mind so I have no doubt you can use modern techniques in some places and continue archaic practices elsewhere. I'm not confused by *INKx, I know what they are. I do not like them for the reasons stated above. You can choose to disregard those arguments but the fact remains that any of the three other methods (*INnn, AID, or named indicators) makes the code far more obvious and intuitive than *INKx. Regards, Simon Coulter. -------------------------------------------------------------------- FlyByNight Software AS/400 Technical Specialists http://www.flybynight.com.au/ Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 /"\ Fax: +61 3 9419 0175 mailto: shc@flybynight.com.au \ / X ASCII Ribbon campaign against HTML E-Mail / \ --------------------------------------------------------------------
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.