RE: Procedure Parameter Change (was Exported Variables)

Paul,

Maybe the example I gave is the only time one would change a procedures
parameters, but for me it's the most common (and possibly only, aside
from the addition of a parameter at the end) that I've had to modify a
procedure parameter.  So when I keep seeing _never_ change a parameter
in a procedure, I had to get some clarification for myself.

I appreciate the time you've put into these emails.  The examples and
situations you've put forth make sense and I can understand the logic
behind coding it the way you're saying.  I think we were possibly
looking at this with different examples in mind.  All in all, it's made
me think more about procedure definition.

Thanks,
Kurt 

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Paul Morgan
Sent: Wednesday, January 12, 2005 10:14 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Procedure Parameter Change (was Exported Variables)

Kurt,

I don't believe this is a style argument.  Style refers more to a coding
standard that improves readability and understanding of a program.  A
style argument against LIKE would be a decrease in readability.  You
have to track down the referring variable to determine the type and size
of the LIKE
defined variable.   That slows down the reading and understanding of
programs using LIKE definitions.  I'm not arguing against LIKE on style
grounds.  In this case I'm arguing that LIKE on a procedure interface
can be a source of programming errors.

In your example I wouldn't have a beef about changing a const parameter
from 1A to 3A.  The calling program wouldn't care about this change.  It
can continue to be fat, dumb and happy passing a 1A value to a 3A const
parameter.  This slight change doesn't really impact the calling
program.

However, what if the LIKE definition switched from 1A to 1P 0 (single
alphanumeric to single packed number)?  Compile errors with the calling
program?  A run time error when the calling program tried to pass a 1A
parameter to a service program expecting a 1P 0?  Not good.

Here's another example.  How about a function defined as:

D FieldA                            1A

D Function       PR               LIKE(FieldA)
D  Value                             1A Const

My calling procedure would be using it as:

D Result                     1A

 Result = Function('X');

What if FieldA went from 1A to 3A?  I'd start losing some data in my
calling program as a result of the function changing.  This is an
'accident waiting to happen' in the calling program because of the LIKE
define in the prototype.  The calling program's compile wouldn't
complain that the returned value was now 3A.  The  calling program would
start truncating the returned 3A value without a complaint.  This is a
'silent' error in the calling program.

Instead of using the LIKE definition to automatically modify Function
I'd make a new Function2:

D Function2  PR                3A
D  Value                            1A Const

then leisurely modify the calling programs to use Function2 instead of
Function.  Meanwhile Function 'gracefully fails' when it encounters an
actual 3A value.  Maybe that 3A field only has 1A values until the
switch to
Function2 has been completed.  Maybe taking the first or last char in
the 3A field is ok.  Maybe Function reports a problem with encountering
an actual 3A value when it can only return a 1A value.  Would depend on
the situation.
It's up to Function to handle the problem and not the Function callers.

Coding an immutable procedure interface (API) isn't really related to
ILE programming.  It's just good software engineering which applies to
any language.  LIKE definitions are a feature of the RPG language - not
just ILE.  IMHO using a LIKE define for an OPM program entry parameter
is also a bad idea.

Paul

--
Paul Morgan
Senior Programmer Analyst - Retail
J. Jill Group
100 Birch Pond Drive, PO Box 2009
Tilton, NH 03276-2009
Phone: (603) 266-2117
Fax:   (603) 266-2333

"Kurt Anderson" wrote

> Why allow the program to give a soft error about something that should

> have been allowed in the first place if the coding was done?  Not to 
> mention it seems that having to code this check into every place the 
> procedure is called is far more tedious than actually modifying the 
> procedure parameter.

> How would the program know?  What if 'A' and 'ABC' were valid, giving 
> a general situation, it couldn't know that it received 'A' when it 
> should have received 'ABC' because 'A' is a valid code.
>

> Say we have the following:
>
> file:
> FileA: FldA 1A
>
> Procedure:
> D ProcA           PR
> D  FldA                          1A   Const
> D  FldB                         10A
>
> Procedure call:
> FileA( code_likeFldA : anotherfield );
>
> Then the file was modified to be:
> FileA: FldA 3A
>
> My thought is: modify the procedure to be 3A instead of 1A (which I 
> think you're saying is wrong, or more prone to problems).
>

> Thanks again for sticking with me here.
> I've been in ILE for not quite a year, and while I've learned a lot, 
> there's a lot more yet to learn.



--
This is the RPG programming on the AS400 / iSeries (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.