Chris, >The Beef is in trying to maintain someone else code who used the CF specs >and went hog wild. I'm sorry. I just don't see the problem in reading indented code. IMHO, the inverse is true -- having multiple nest levels with all opcodes aligned is harder to read. Maybe it is just me. Or maybe by hog wild you meant the programmer was sloppy and didn't align or indent the code with any recognizable pattern. But utility programs (ie freeware or magazine code) should be able to take either C or existing CF and refromat it into properly indented CF. What does going "hog wild" with CF specs mean to you? If the problem is too many nest levels, then it is not really a syntax or feature issue. People can write ugly code regardless ot the syntax. It is a matter of having shop standards, and following them. At some point you need to move nested logic to a subroutine or subprocedure to maintain readability, even with nested code. But again that is not a language issue -- it is a standards issue. >Plus I am a lousy typist, love the prompting of SEU as >well as the online help. How is that going to work for CFs? I don't know what will be done to SEU, if anything. But I'm not convinced it matters that much, for a few reasons: - Only C specs are affected, so prompting and help of other types will not change. - The biggest advantage of c-spec prompting (IMHO) is for the ability to use Field Exit or Tab for the column alignment. Since this is a non-issue with free-form calcs, it follows the prompting will be less useful for CF specs. (Do you prompt comments?) - The prompting and help in SEU is not that intelligent anyway, as it is not op-code specific. Have you tried the prompting in CODE/400, Code Studio, or Flex Edit? The prompt varies with the opcode and changes the headings of the input fields based on what they mean for that particular opcode. And if you press Help, you get Help specific to that opcode. - And besides, I don't use SEU, so when it comes down to it I really don't care how it handles CF specs. >>Maybe the compiler can have an option to realign CF specs into rigid >columns for people who don't like indented source but are forced into >maintaining a program with CF specs! How about it Hans? :) > >That should be a requirement before CFs are introduced. My comment was tongue in cheek. I don't think it should be a requirement. Just like I don't think it should be required of IBM to provide a conversion utility for C to CF source. Just change the compiler to allow it (like it does in the lab), and let third-party vendors, magazine utility authors, and shareware/freeware writers fill the void. This lets IBM concentrate their efforts toward other compiler improvements, but lets them release what is already done in the lab. I still fail to see the problem here. We are not talking about taking away any existing functionality. Nor are we talking about a significant reduction in other new features because of resources devoted to CF. It is not like IBM doubled our "feature budget" from $100 to $200. Hans and crew just thought about it, tried some experiments and realized it would not have the major impact on compiler phases they first suspected. As programmers, haven't we all at times had the pleasure of finding out something is much easier than first envisioned once you actually did a little planning and pilot test? And haven't we all, at one time or another, spent a few hours trying something for our own satisfaction even if is was not the top thing on the priority list, and we needed a little mental break from what we were doing? Don't shoot Toronto just because Hans et al decided to do a little feasibility test and it was successfull. If Hans and Barbara (et al) were that hard pressed for time, we'd never see their involvement here. And their presence has helped us shape and improve the language. Listening to things like complaints about source statement number mismatches, debug I/O stepping, BIF suggestions, etc. I for one am thankful for their presence. Don't shoot the messenger. Doug +--- | 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: email@example.com +---END
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.