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