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

Larry,

This thread has moved on somewhat from the OP's original question.

In his original question (someone tell me if I'm wrong) he was calling one
procedure (proc2) from another 'middleman' procedure (proc1), where the
middleman procedure accepted a long list of parameters, all of which had
*OMIT and *NOPASS defined. Therefore he was forced to use a long SELECT
statement to cater for all possible scenarios.

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.

If you also have to check for parameters being omitted, then you potentially
have to check for every possibility, e.g.:

if %parms = 3;
select;
when %addr( parm1 ) = *null and %addr( parm2 ) = *null and %addr( parm3
) = *null;
callp proc2 (*omit : *omit : *omit );
when %addr( parm1 ) = *null and %addr( parm2 ) = *null;
callp proc2 (*omit : *omit : parm3 );
when %addr( parm1 ) = *null and %addr( parm3 ) = *null;
callp proc2 (*omit : parm2 : *omit );
when %addr( parm1 ) = *null;
callp proc2 (*omit : parm2 : parm3 );
when %addr( parm2 ) = *null and %addr( parm3 ) = *null;
callp proc2 (parm1 : *omit : *omit );
when %addr( parm2 ) = *null;
callp proc2 (parm1 : *omit : parm3 );
when %addr( parm3 ) = *null;
callp proc2 (parm1 : parm2 : *omit );
other;
callp proc2 (parm1 : parm2 : parm3 );
endsl;
endif;

and that's only with 3 parms being passed in...

Various posters then started discussing about why the middleman couldn't
simply call proc2 as:

callp proc2 (parm1 : parm2 : parm3 );

even when some of the parms might have been omitted in the call to the
middleman.

At least, that's how I understand the conversation...

Rory

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 :)


On Thu, Mar 10, 2011 at 1:47 PM, Larry Ducie <larry_ducie@xxxxxxxxxxx>wrote:

Hi All,

OK, admittedly I am coming into this thread very late and probably
ill-informed about the ongoing debate but...

I fail to see the problem with the way in which we check for valid
parameter access in RPG.

What is difficult about:


parm3 in proto with *OMIT : *NOPASS
local3 like parm3 in local D-specs (optionally initialised to a non-default
value)

if %parms() >= 3 and %addr(parm3) <> *null;
local3 = parm3;
endif;

work with local3...


This logic is obvious and clean. the procedure ONLY accesses local3, with
the exception of populating it from parm3, if passed.
It ensures you ALWAYS check %parms() BEFORE %addr() if *OMIT and *NOPASS is
specified for a parameter:
1) *NOPASS: Is a parameter passed?
2) *OMIT: Is the address of the passed parameter a null?

As *OMIT passes an address (albeit a null address) it will count as a
parameter when checking %parms(). Calling myProc(*OMIT : parm2 : *OMIT :
parm4) will set %parms() to 4 inside myProc. So check it is passed before
checking its address is null.

This code also gives you the ability to initialise local3 with a
non-default value to be used if parm3 is not passed. Parm3 is simply an
override value.

When using this in a procedure overloading scenario - you simply call the
other procedure passing the additional data using the local variables.

This is a similar mechanism to overloading constructors. The constructor
that takes the most parms usually performs the work. The other variants
simply supplement the missing parms with locals (derived or otherwise) and
call the full constructor.

Cheers

Larry Ducie