RE: Procedure Parameter Change (was Exported Variables)

<quote>
I use LIKE because I'll have one master place where I define abstract 
"data types".  Customer Number, for example, is a data type.  As is item 
number.

Every program, file, screen, etc. that uses a customer number should be 
defined in exactly the same way.  And that includes parameters!  I don't 
ever plan to change the type of field I store a customer number in, but I 
want to make sure that it's always the same across all programs...
</quote>

I agree with using like for the purposes defined by Scott....However I do
have misgivings about programmers using like() too often in the wrong
circumstance.  It's like many things in programming...how it's used
determines if it's a threat or a tool...

Thanks,
Tommy Holden


-----Original Message-----
From: Scott Klement [mailto:rpg400-l@xxxxxxxxxxxxxxxx]
Sent: Wednesday, January 12, 2005 1:01 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Procedure Parameter Change (was Exported Variables)



> file, and I may need to change the programs as well. How is changing a
> procedure parameter any different?

It's different because it's unnecessary. Changing a file is often 
necessary, but changing a procedure's parameters usually isn't.  Instead, 
you create a new procedure that has different parameters and use that 
where it's needed.

Having said that, however, I agree that it's okay to change a procedure's 
parameters -- particularly when you know that you'll never need the old 
interface in any programs again...  no point in keeping it around.

I also think the idea that LIKE() is somehow bad for parameters is absurd. 
The use of LIKE() does not, IMHO, encourage change.  It encourages 
CONSISTENCY which is very important.

Paul seems to be implying that you make one field like another field so 
that if you change one, both will change -- which is an interesting 
philosophy, but it's not the reason I use LIKE.

I use LIKE because I'll have one master place where I define abstract 
"data types".  Customer Number, for example, is a data type.  As is item 
number.

Every program, file, screen, etc. that uses a customer number should be 
defined in exactly the same way.  And that includes parameters!  I don't 
ever plan to change the type of field I store a customer number in, but I 
want to make sure that it's always the same across all programs...


> The change in the service program's signature will prevent me from 
> unknowingly using a changed procedure, and if it is in a bound module, 
> the procedure won't change until I rebind the program at which point I 
> will hopefully either be changing the main module code or at least get 
> an error indicating the the procedure call is no longer correct.

Sorry, this is not true.  Changing a parameter will NOT change a service 
program's signature.  Parameters are NOT incorporated into the signature. 
Only the procedure's name is part of the signature.

That's why I always recommend the use of hard-coded signatures in your 
binder language, and NEVER use *GEN.  That way, if you make an 
imcompatbile change, you can FORCE the signature to change, providing you 
with some protection.

Hard-coding the signature also has the really nice side effect of allowing 
you to add new exports to the end of teh list without needing to create an 
additional "previous signature" block of exports -- which, frankly, after 
about 10-15 changes to the service program's exports becomes unmanageable.

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