RE: New parameter needed for a subprocedure

I just want to address the comment about output parameters being a bad design technique. It's good design. Ok, that's my opinion. Output parameters are passed by reference (16 bytes). Return values are passed by value. Which is fine generally, although can become unwieldy. Also, forcing all output to be in the form of a return value can often times require adding a data structure to the program for no other reason than to pass multiple output fields as a return value.

I like to use my return values as a means of passing back unexpected errors, either as an indicator (pass/fail) or as an integer if I want to break out different errors.

I guess it comes down to personal choice and style, so long as people err on the side of readability. I won't say not using output parameters is bad design, but I don't agree that using them is either.

I wouldn't mind hearing the justification of why using output parameters is bad.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael_Schutte@xxxxxxxxxxxx
Sent: Monday, March 16, 2009 12:09 PM
To: RPG programming on the IBM i / System i
Subject: RE: New parameter needed for a subprocedure


Personally, I think it's bad design to pass output parms in the parm list.
(not saying that i haven't done it). Procedures allow you to return a
value so why not use the return functionality. This may not be the best
solution, but when I have a procedure that needs to return two values, I
just return a data structure.

ie.

D GetRecipeID PR Like(GetRecipeDS)
D iCono 3 Const
D iCpy 3 Const
D iItem 9 Const
D iParent 9 Const Options(*NOPASS)

D GetRecipeDS DS
D RecipeID 11 0
D RecipeQTY 17 6

/Free
// Main pgm

GetRecipeDS = GetRecipeID(pGLCPY:pCpy:PosItem:' ');

/End-Free
P GetRecipeID B
D GetRecipeID PI Like(GetRecipeDS)
D iCono 3 Const
D iCpy 3 Const
D iItem 9 Const
D iParent 9 Const Options(*NOPASS)

D Parent S 9
D Item S 9

D rtnRecipeDS DS
D Recipe 11 0
D Quantity 17 6
/Free

Item = iItem;
Parent = *Blanks;
If %Parms() >= 4;
Parent = iParent;
EndIf;

// cumbersome code removed....


Recipe = NKRCP;
Quantity = NKQTY;
Return rtnRecipeDS;
/End-Free
P GetRecipeID E


Michael Schutte
Admin Professional



We've wrapped up a whole new breakfast adventure in Bob Evans BOBurrito.
Premiering at 5.99. For more information and to enter the FREE Breakfast
Every Week for a Year Sweepstakes ($500 value), visit www.BOBurrito.com


rpg400-l-bounces@xxxxxxxxxxxx wrote on 03/16/2009 12:57:21 PM:

Thanks. I feel that makes for a messy procedure interface when the
original procedure was designed with input parameters followed by
output parameters, then someone sticks a nopass input on the end,
and later someone else a nopass output parameter.

Is there anything wrong with my suggestion?

-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-
bounces@xxxxxxxxxxxx] De la part de Michael_Schutte@xxxxxxxxxxxx
Envoyé : lundi 16 mars 2009 17:44
À : RPG programming on the IBM i / System i
Objet : Re: New parameter needed for a subprocedure

I think I understand what you want. Here's my suggestion.

In the prototype and interface, add the new parm and make it the last
parm. Use options(*Nopass) on the keyword of this new parm.


D SomePRC PR
D Parm1
D pNewParm 1 Options(*NOPASS)

D SomePRC PI
D Parm1
D pNewParm 1 Options(*NOPASS)

D NewParm S

/Free

NewParm = *Blanks;
If %Parms() >= 2;
NewParm = pNewParm;
EndIf;

/End-Free



Then you can change only the program(s) that need to pass that new parm.
All others remain as is.

Michael Schutte
Admin Professional



We've wrapped up a whole new breakfast adventure in Bob Evans BOBurrito.
Premiering at 5.99. For more information and to enter the FREE
Breakfast Every Week for a Year Sweepstakes ($500 value), visit www.
BOBurrito.com


rpg400-l-bounces@xxxxxxxxxxxx wrote on 03/16/2009 12:32:05 PM:

A new parameter is needed by one of the callers of an exported sub

procedure.

Is there any harm in doing this :

Initialize the value of the new parameter in the exported sub

procedure.

Add a new exported subprocedure GetNewParameter that returns

NewParameter.

The caller that needs the parameter continues to call the original
subprocedure as before and then calls GetNewParameter.

Other callers remain unchanged.

Does this make sense or is this just being lazy and are there any
risks of it going wrong?

Thanks
--
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.

--
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.