On 04/12/12 04:57, Israel, John R. wrote: > As far as the number of arguments changing, I will often write a subroutine > with a few extra variables (FUTURE1, FUTURE2, FUTURE3) so that I do not need > to find all the existing programs that call it and recompile them. It makes > this sort of thing a piece of cake. The existing programs will likely not > need to populate the arguments other than initialized to null. > While I didn't know about it way back when, you can actually test a variable for "unassigned" so if you do that, you can just start your subroutine with "if future1 is unassigned then set to null" etc.
Cheers, Wol > John Israel > > Sent from my iPhone > > On Dec 3, 2012, at 9:28 PM, "Kate Stanton" <[email protected]> wrote: > >> I would hate to see that in our software, as it would be so hard to find >> where a subroutine is used. >> >> On the odd occasion we use this form (eg call depends on transaction type), >> we do the definition just above, so it can be found. >> >> In my experience, the number of parameters is more likely to change that >> the subroutine name. >> >> On 4 December 2012 13:38, Wjhonson <[email protected]> wrote: >> >>> I've not encountered this is my career previously, but now I'm seeing a >>> system written almost entirely with the use of indirect calls in Universe >>> BASIC. >>> >>> That is >>> SOURCE = "*SOME.PROGRAM" >>> ... >>> CALL @SOURCE(INPUTS) >>> >>> Is there some advantage to the use of indirect calls that a system would >>> be written entirely in this fashion? >>> >>> _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
