AW: Procedure Parameter Change (was Exported Variables)

Hi Paul,

think about the following situation:
You have a modularized application with thousands of (sub-)procedures.
Until now the item no is defined as 10A, but your client wants to
expand the item no to 15A.
Do your really want to change thousands of prototypes?
(and how much of these prototypes aren't changed by hazard?)

If you have a file reference file and put it as template in your D-Specs
as follows:
D RefFileTmp      E DS                extName(RefFile) based(DummyPtr)

Then every field you need either global/local variable, prototype, fields
in physical, display or printer files is referenced on fields in this
reference file.
There is no danger of unexpected changes in prototypes or procedure
interfaces.

If you really have to change something, you change the field in your
field reference file and recompile your application.

Birgitta


-----Ursprüngliche Nachricht-----
Von: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]Im Auftrag von Paul Morgan
Gesendet: Mittwoch, 12. Januar 2005 22:16
An: rpg400-l@xxxxxxxxxxxx
Betreff: Re: Procedure Parameter Change (was Exported Variables)


Scott,

Absurd?  Isolating changes in an application is more important than your
principal of consistency.  Consistency within a module or program is ok.
Consistency across a module or program boundary is bad.  Consistency across
a module boundary spreads change throughout an application.  Isolating a
change to only a portion of an application is good.  Wanting to propogate a
change throughout an application is courting trouble.  Using LIKEs in
prototypes and procedure interfaces encourages widespread change in an
application and prevents the isolation of changes.

Using LIKE to make a work field match another field is the way it works in
practice.  Vendor packages we use do have field reference files that define
their domains (your abstract data types).  My program uses their files but
not their field reference file.  I'm going to LIKE define my program work
fields from their file fields instead of their field reference files.  So I
end up using LIKE defines to make my work fields match their file fields.
In my files I'll use their field reference files (or our own field reference
file which refers to their field reference file) but my examples haven't
shown DDS.

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
"Scott Klement" wrote


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



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