× 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.



​well crap....

Turns out there's already some additional RETURN op-codes in the mainline...

So in order to convert the *ENTRY PLIST that uses factor2 to PR/PI, the
@END_PROGRAM subroutine is probably my best bet....

Otherwise I've got to add the eval of parm12 = *IN12 into multiple places...

Yeah, one line isn't a big deal...but I'm trying to document a general
technique.

Charles


On Thu, Oct 12, 2017 at 1:12 PM, Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

On Thu, Oct 12, 2017 at 12:07 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 10/12/2017 1:43 PM, Charles Wilt wrote:
Looking at an old program that using GOTO...I'd like to get rid of it.

---Option 1---

dou *on = *on; //run once
//mainline part1
if something leave
//mainline part2
if somethingelse leave
//mainline part 3
enddo;
eval parm12 = *IN12;
return;

I've seen a lot of code. I'm not keen on GOTO myself, but this kind
(early exit) is the least troublesome for my brain. I'm not one to
argue that LEAVE is GOTO with an accent; it's a forward-only jump to a
single destination, so it's pretty easy to grok the intent.

This pattern is nice because when I go to add a new condition, the LEAVE
is automatic in my head due to the DO. So when I'm maintaining this a
year from now I'm unlikely to break it by adding new code. The downside
is that the DO triggers an expectation of a loop.


​I agree, and it'd work in this case. But I'm think ahead to other
programs where there's a GOTO @END inside an existing loop.​


---Option 2---

//mainline part1
if something exsr @END_PROGRAM
//mainline part2
if somethingelse exsr @END_PROGRAM
//mainline part 3
...
exsr @END_PROGRAM
//shouldn't get here, but to be safe
return;

begsr @END_PROGRAM;
eval parm12 = *IN12;
return;
endsr;

Although I've done this, I don't care for it. EXSR is hard-wired in my
head that the code will go there _and come back_ -- but it never does in
this case. The name @END_PROGRAM is a good hint about that though :-)


​Yeah, that's probably why I'm not satisfied with it.​



Some of the programs I work on are monstrous in terms of lines of code.
So I might not readily see that early exits are happening via EXSR and I
might be tempted to put a RETURN in there which would break the code.

There is another pattern which you might consider:

success1 = mainline_part1(parm: parm: parm);
if success1;
success2 = mainline_part2(parm: parm: parm);
if success2;
success3 = mainline_part3(parm: parm: parm);
...
else;
// report the issue
endif;
else;
// report the issue
endif;


Unfortunately, I'm doing "small step" refactoring...I want the differences
to be small and easily recognized as not changing the logic.

I'm not sure the above would fit the qualifications...

But I do like that I could give "mainline_part1" a useful name...asuming I
could come up with one! ;)

Charles


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.