Re: Calling similiar (overloaded) procedure that has *nopass *omit in the parameter

Hi Rory,

Thanks for taking the time to get me up to date!

<snip>
For instance, the below example simply checks for 5 parameters with *NOPASS

specified, and doesn't even get into the *OMIT problem:



if %parms = 1;

callp proc2( parm1 );

endif;

if %parms = 2;

callp proc2( parm1 : parm2 );

endif;

if %parms = 3;

callp proc2( parm1 : parm2 : parm3 );

endif;

if %parms = 4;

callp proc2( parm1 : parm2 : parm3 : parm4 );

endif;



and so on.



Sure, it works, but if the parameter names being passed into this procedure

are longer than the 5-character examples I give above (which of course they

are), then the code just gets very long and unwieldy, since each CALLP

statement would span many lines.
</snip>

I would put this in the category of 'collateral damage'. That is, it is a necessary evil. If we want to effect overloading cheaply then we have to accept compromises. As all this procedure does is build an appropriate call to proc2 the code is acceptable and self-documenting.


<snip>
If you also have to check for parameters being omitted, then you potentially

have to check for every possibility, e.g.:

...
and that's only with 3 parms being passed in...
</snip>

In the example provided by the OP (and by inference your extended example) you don't need to check for omitted parameters in proc1. You'd just pass them on. A null address would have been passed for each of the omitted parameters and they count towards the %parms() value. Only optional parameters should be of concern as they influence the number of parameters you make the call to proc2 with. This ensures proc2 has the same %parms() value proc1 received. It would be up to proc2 to handle the omitted parameters because it is proc2 that will actually reference them.

<snip>
p.s. I actually posted a solution for the OP's problem which is only about

15 lines total, but no-one had anything to say about it, which may be just

as well :)
</snip>

I think in this scenario the big select/if statement is ugly but reasonably straightforward and very simple to implement/maintain. Your solution is technically neat but requires many more working parts and a deeper knowledge for the next guy who comes along. I will certainly have a play with your code though!

Of course, if OPDESC/CEEDOD supported packed/zoned/dates/etc then we could really get cooking with 'overloading' procedures. I knocked up a quick proc that would take a packed/char/zoned/date in the same parm - only proc1 needed in this scenario. This example does not work by passing the address by value. It uses 4 different prototypes (packed/zoned/char/date) for the same procedure. The parms are passed using const to allow such things as passing a 13p2 and having the caller convert to a 15p5 before the call. I could see the 4 different values/types on the various calls but it would be difficult to interpret which format was actually passed. Sadly CEEDOD only worked for the char - the others don't pass the right kind of descriptor (if at all). I guess a 'type' parm could be passed but that is just manually providing operational descriptors and is not very nice. Would be much nicer if the ILE runtime did that for us. :-)

Cheers

Larry Ducie