Re: Procedure Parameter Change (was Exported Variables)

["Paul Morgan" <pmorgan@xxxxxxxxxxxxxx>]

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.