Re: Additional RPGLE Enhancement Requests

[Buck Calabro <mcalabro@xxxxxxxxxxxx>]

Lloyd,

>On Fri, 18 Jul 1997 15:24:47 -0400, Buck Calabro
><mcalabro@commsoft.net> wrote:
>
>>The point of this discussion was to suggest possible ways to use structured
>>code; to avoid the GOTO.  I understand that the *current* language definition
>>requires me to have matched BEGSR ENDSR pairs.  I'm suggesting a change
>>to that specification..
>>
>>Other folks in the discussion were suggesting a new opcode to "leave a 
>>subroutine early."   I just thought that we already have a "leave 
>>subroutine" (ENDSR) opcode; why not simply reuse it for the case when 
>>we want to leave early?
>
>Being totally serious here, do we also want multiple ENDDO/ENDIF ops
>so we can terminate our loops and conditions early? The last thing I
>want to see when looking at someone else's code is an END* when it's
>really not ending, ie, not the end of the structure. The whole point
>is to (easily) determine where a structure begins and ends. This is
>even more important with fixed-format (non-indented) code..

Nope, I wouldn't want that, but then I didn't suggest that, either! <grin>

>In terms of programming logic, a GOTO *ENDSR or LEAVSR variant is
>totally acceptable, it's the same implied thinking behind
>LOOP/LEAVE/EXIT - we're terminating the structure early..
>
>Some will comment that "if you code correctly, logic will fall through
>to the end". In strict textbook/structured programming terms, that's
>okay, but in terms of practicality I'd rather have LOOP/LEAVE/GOTO
>with a comment stating why instead of conditioning everything in my
>structures "just to" make it fall through. It can hamper readability
>and maintainability..
>
>In terms of the above, using GOTO does not lead to spaghetti code but
>overcomes a limitation of the language. In this case, the need to exit
>a subroutine early..

I rather agree with every point you've made...  Following your thoughts
on practicality and readability, it didn't seem that hard to understand:

CONDITION IFEQ TRUE
                    ENDSR
                    ENDIF

Since it seemed simple and readable (to me) I tossed the idea out for
comment...  Your remarks on balancing readability and practicality
are an excellent synopsis of the problem of writing code in general.
Well put!

Buck Calabro
Commsoft, Rensselaer, NY
mcalabro@commsoft.net

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *