× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I don't have a problem with the semicolon.  Granted, it's not consistent
with other languages and yes I do forget one here and there, but I don't see
it as a big deal.

I think you have a very valid point on the multiple chain syntaxes. 

Charles Wilt
iSeries Systems Administrator / Programmer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
 

> -----Original Message-----
> From: Bob Cozzi [mailto:cozzi@xxxxxxxxx]
> Sent: Thursday, October 28, 2004 7:49 PM
> To: 'RPG programming on the AS400 / iSeries'
> Subject: RE: /free vs Fixed (was: RPGIII to get a facelift?)
> 
> 
> 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 
> 
> 

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.