×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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 mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
