RE: RE: creating a new procedurethatcallanexistingprocedurewithoneadditional parm

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Hewitt, Rory
> Sent: Wednesday, July 27, 2005 1:19 PM
> To: rpg400-l@xxxxxxxxxxxx
> Subject: RE: RE: creating a new
> procedurethatcallanexistingprocedurewithoneadditional parm
> 
> 
> Not wanting to flog a dead thread, but...
>  
> Using the example:
>  
> MyProc(parm1:*omit);
> MyProc(parm1);
> 
> If your procedure only has 2 parameters, there's NO good 
> reason you would specify the second parameter as omittable anyway!

True, but it was just an example.


>  
> Omittable parameters are only really of any use as 
> 'placeholders', where you may want to omit certain parameters 
> in the middle of a *PLIST (e.g. pass parameters parm1 and 
> parm3, but not parm2). In that case, defining parm2 as 
> omittable (and adding code to your procedure to cater for 
> this, obviously) is necessary.
>  
> But if you'll only ever pass parm1 OR parm1 and parm2 OR 
> parm1 and parm2 and parm3, then making any of the parameters 
> omittable is pointless - just make then *NOPASS and use %parms.

But if sometimes you only want to pass parm1, parm3, and parm5...

Then *OMIT is needed.

>  
> A good technique is to design your interfaces so you never 
> need to use omittable parameters (but then I was using V4R5 
> until recently, so had to use CEETSTA rather than checking 
> for %addr...). In my experience, it's rare that you NEED to 
> have an omittable parameter.

I disagree, it depends on the flexibility built into the procedure.

I tend to always make parms *NOPASS and *OMIT as I believe that if a parameter 
is optional, I shouldn't have to pass some default value for parm4 when all I 
really want is to pass parm5.


>  
> MOST (but not all, I hasten to add) procedures can be defined 
> with required parameters first and then everything else as 
> *NOPASS. Hell, in some cases, I've designed a 'real' 
> procedure which does some actual work and multiple 'wrapper' 
> procedures which accept fewer parameters, and which pass 
> dummy parameters to the real procedure. No-one ever 
> explicitly calls the real procedure (which is never exported 
> anyway), only the wrappers. If I change the real procedure 
> parameters, I can change the internals of the wrappers, or 
> add new ones. It's an alternative to using omittable 
> parameters and I think it's cleaner...
> 


Interesting idea, I'd like it better if RPG allowed overloading and typedefs.

Works ok if you can come up with reasonable names for each procedure and don't 
need the flexibility that *NOPASS *OMIT gives you.

In fact, one place where it works quite well is where you need some conditional 
parms.  If parm5 is needed, then so is parm4.


Charles