Re: RPG IV and CF-spec "keep it IBM"

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: david@midrange.com
+---END