Re: Procedure Problem

Jim,

Your concerns are valid. However, the world is not all black & white. We
need to apply some common sense in most cases. When you see something like
"CallP  Center( SomeVar )", is there really anything ambiguous about it?
Perhaps it would be clearer if I called it "CallP
enterTheTextInThisVar( SomeVar )".   ;-)

Other good examples of this technique are the many AS/400 API's that require
you to pass a receiver variable as the first parameter. Do you abhor those
as well?

And lastly, when writing a procedure interface, I make sure to use the tools
at my disposal to limit any such confusion. For example:

P SomeProc            PR
D   uReturnParm                512A    Options( *VarSize )
D   iParm2                             1A    Const
D   iParm3                             1A    Const Options( *NoPass )

Now, if you actually take a look at the procedure prototype, is it not
patently obvious that the first parameter can be updated, but the second and
third cannot?


John Taylor
Canada


----- Original Message -----
From: "Jim Langston" <jlangston@conexfreight.com>
To: <RPG400-L@midrange.com>
Sent: Thursday, December 23, 1999 00:13
Subject: Re: Procedure Problem


> Now we get into something I think is not good.
>
> I abhor a function or subroutine to change the contents of a passed
variable.
>
> And yes, that is common too, but I think it is much worst than having to
> pass another variable.
>
> As a user of a function, I have to be very aware that a function is
changing
> one or more of my variables.  If I am not aware of this, I can trash my
data
> very quickly.
>
> Consider a function that returns a value and changes a variable.  Such as
> something like (in pseudo C syntax)
>
> /* Function to return the length of a string without leading or trailing
spaces
> */
> int StringLength(char *SomeVar);
>
> Perhaps as a side effect this function modifies SomeVar in some way.
> Such as Trimming it to get the length without spaces.  If I am not aware
> of this I can do somethign like this:
>
> MyVar = '  SomeText';
> MyVarLen = StringLength(MyVar);
> Write(OutFile, MyVar);             /* Write the string to file */
> Write(OutFile, MyVarLen);       /* Write the TRIMed length to file */
>
> Now, not being aware that StringLength changed MyVar and made it
> 'SomeText'.  I now wrote 'SomeText8' or the such to the file (in my
> make believe Write statement).  I thought I wrote '  SomeText8'.
>
> I know that, yes, I should be aware of any side effects of any functions
> I use.  But, this is not always the case.
>
> And, yes, I have been bitten by this one before.  Very difficult bug
> to track down.
>
> PC languages tend to be getting away from this by returning structures
> and not just variables.  So StringLength would return a structure of
>
> struct StringLengthrReturn
>   int TrimmedLength;
>   char *TrimmedString;
>
> or the such, then it doesnt' have to modify the variable.
>
> Regards,
>
> Jim Langston
>
> John Taylor wrote:
>
> > Jim,
> >
> > <SNIP>
> > If you want use a function call, as in Jon's example:
> >
> >     Eval    NiceChar = Center(%Trim(MessyChar): %Size(NiceChar))
> >
> > you're going to have to pass the size of receiving variable. To avoid
this,
> > I just write the routine as a procedure call, so that the centering is
done
> > within the parameter that it's passed in. For example:
> >
> >     Eval    NiceChar = MessyChar
> >     CallP  Center( NiceChar )
>
> <SNIP>
>
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---