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

Larry,

If a procedure has a parameter passed to it as *OMIT, then the address of
that parameter is null. If this parameter is referenced (including simply
passing it to another procedure), could that cause runtime problems?

I assumed (there I go again, making an ass...) that using that parameter
directly could give the same sort of problems as referencing an unpassed
parameter (even though they are very different things).

Essentially, all parameters are based variables and an omitted parameter is
simply one where the basing pointer is null. Thus my concern over passing an
omitted parameter to another procedure...

Rory

On Fri, Mar 11, 2011 at 6:55 AM, Larry Ducie <larry_ducie@xxxxxxxxxxx>wrote:

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



--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.