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

[Rory Hewitt <rory.hewitt@xxxxxxxxx>]

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.