The /free syntax is just too troubling for me. And this is coming from a 12+
year C and C++ programmers (in addition to all the flavors of RPG). 

I could live with the /free and /end-free in the code; those things are the
least of my concerns. The damn inconsistency with other languages and within
itself is what bothers me most about the /free syntax. 
For example, I can't say this:

  if  (A = B) 
    For I = 1 to %size(Custname) by 1;
    //  blah, blah, blah,
    Endfor;
  else
    //  do something else here.
  endif;

Instead I have to code this:

  If (A=B);
    for I = 1 to %size(Custname) by 1;
    //  blah, blah, blah,
    endfor;
  else;
    //  do something else here.
  endif;

Where's the issue?  The semicolon on the IF and the ELSE statements. 
I can get used to entering /Free and /end-free once, but when you code 10
million IF statements in your lifetime and for 9,999,995 of them you forget
to enter the ; and have to recompile, it gets to be bothersome.

Then there's the very extensions to the opcodes in free format that I'm
beginning to dislike a lot. Take the CHAIN opcode. I love the ad hoc keylist
idea. It is a wonderful feature, but then, instead of allowing us to simply
use data structures as keylists or allow us to declare key lists on D specs,
they added that "opcode parameter keyword" thing.  So now we have 3
different free format syntaxes for the CHAIN opcode. That in addition to the
fixed format CHAIN syntax. 

Rules for CHAIN in Free Format:
 If you use a KEYLIST, then just the keylist name is specified.
 If you use an ad hoc keylist, enclose the fields in parentheses. 
 If you want to use data structure subfields are key fields, specify the
data structure name and enclose it in a %KDS() parameter keyword.

If the free format syntax is so much better, why all the extra syntaxes "if
this, then do this, else do that" I mean just try teaching this to
students... They many get turned off to /FREE immediately even though they
love the ad hoc keylist capability. 

If data structures did not fit the ad hoc keylist model, that is allow them
to simply be enclose in parens, then data structures should not have been
allowed. In stead, keylists should have been allowed on the D spec and
specified as usual (with no parens) then if you only want to use a partial
keylist (a subset of the fields in the keylist) enclose the keylist in
parens and specify the number of fields to use as the 2nd value, like thisL
  Chain myKeyList  CustMast;
  Chain (myKyelist: 2) custmast:
In fact,
  Chain (myKeyList) Custmast;
Should also work today, but it does not (as far as I remember).

For those who say, "I already have a data structure created that has the
keyfields I need, why not allow %KDS?" I say, why not this instead:

D  MyKeyList          KL             LIKEDS(MyKeyDS)


-Bob 


-----Original Message-----
From: rpg400-l-bounces+cozzi=rpgiv.com@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+cozzi=rpgiv.com@xxxxxxxxxxxx] On Behalf Of Jon
Paris
Sent: Thursday, October 28, 2004 6:19 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: RPGIII to get a facelift?

>> I'd go to it for the 'pretty code' factor so I could indent my code.  
What other reason is there to use it?

How about the opcode extensions that _only_ work in /Free and the
probability 
that more of these will appear in the future.

Jon Paris
Partner400
www.Partner400.com
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.