Re: What are the dangers of changing the return type of a subprocedure?

Mike,

You rarely need to worry about changing the return type of a procedure if
you have control over the prototype and all callers of the procedure and
can change them all at once.

Seems to me that the procedure is named correctly -- it returns the next
NUMBER. Problem is going to be that your "formatting" of the completed
Invoice "number" will be scattered all over creation once those other
facilities begin generating Invoice numbers. That whole "formatting"
business with the date really ought to be boxed up somewhere in a common
"Invoice" set of routines.

Personally I'd rename the procedure to GetNextInvoiceIdentifier() and have
it do the generation of the sequence and the date-related formatting so
that it only exists in one place. Have all current and future callers use
it. If you return a sufficiently large character value (say 32 bytes), you
will have fewer issues in the future with format changes (long as you stay
under 32 bytes). You will need to locate and recompile all current callers
of the procedure such that they use the new procedure and do not format the
number any longer.

'Course, I'm rarely concerned with the scope of a change here as I have
time for verification and testing. If scope is an issue, make a new
procedure and phase it in as you encounter that procedure in the various
callers.

Stu



On Fri, Feb 10, 2012 at 09:54, Mike Wills <mike@xxxxxxxxxxxx> wrote:

I don't know what I was thinking when I wrote it (I'm sure I thought I was
cleaver) but I wrote a subprocedure that pulled the next invoice number.
That in itself is good, but then in the calling code, I had to do this:

dInvoice = %subst(%char(%date():*iso):1:7) + '-' +
%subst(%editc(GetNextInvoiceNumber():'X'):2:7);

WHAT THE?!? Ideally it should be:

dInvoice = GetNextInvoiceNumber();

Normally I wouldn't re-factor things like this, but now other software will
soon be creating invoices and needs to get invoice numbers. What dangers
are there in changing the subprocedure from a decimal return field to a
character? I have tracked down all of the programs that call this function
(that I know of). Or should I create a new subprocedure and leave the old
one just in case I missed something? For course if we change the format of
the number, we will quickly have problems that way.

--
Mike Wills
http://mikewills.me
--
This is the RPG programming on the IBM i / System i (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.