Externalising opcodes (was: Converting to upper case)

[Buck Calabro <buck.calabro@xxxxxxxxxxxxxxxxx>]

Dan Bale wrote:

>In theory (gotta have a copout!), I concur with your laudable 
>goal of centralization & encapsulation.
>
>I see at least one risk, however.  You mention the ability 
>to enhance your functions.  Say you've got a particular 
>function used in hundreds of applications.  You make 
>an enhancement to it.  Are you going to test those
>hundreds of applications that use it?  If not, why not?  

No, I won't test the hundreds of applications that use it.  I don't need to
because the function has a clear and well defined interface: parameters.
XLATE is a good example of this.  Input: fixed length string, translation
table. Output:fixed length string same size as input string, translated
character for character (Caesar cypher) by the translation table.  Input
characters not found in the translate table are placed into the output
string unchanged.  

I write the function, build a test harness (no more boilerplates! :-) ) and
see if it passes or fails.

Another great candidate for "externalisation" is LOKUP.  Performance-wise,
LOKUP can use some help.

>How can you know that what you considered an 
>enhancement does not actually introduce an error into
>one program that has a "special case"?

Because the function doesn't know anything about the caller and it doesn't
tell the caller anything about itself.  My theoretical LOKUP function has a
user space and a bunch of variables and pointers.  All of that stuff is
internal to the function, so if there's a bug with allocating storage, only
the pointer in my function is messed up - not the calling program.  

Philosophically, it's diametrically opposed to the monster programs we wrote
in the Dark Ages.  You know, the ones where we do EXSR CHKCUS and as long as
we did a CHAIN to CUSMAS we might as well check the credit status.  And as
long as we're in the credit history file we may as well update the current
A/R balances.  If my new function needs more than one parameter to return
it's results, I think long and hard to see if I've broken it down far
enough.

This whole thought process is tied intimately to the "lines of code" debate.
More is WORSE, not better!  The smaller my functions are, the better they
are - fewer lines of code to cause a bug.  It's easier to prove that a small
function works as required.  Then I can build a more complex function up
from my building blocks.  In the case of my LOKUP example, I might have a
dozen small functions: createSpace, deleteSpace, insertEntry, etc.  Could I
put them all as "mainline" for a lookupElement function?  Sure, but then the
different parts might interact with each other in unforeseen ways.  By
building the small ones first, the complex one is made simpler and more bug
free.  

I end up with a dozen sub-function primitives that each have a dozen lines
of code.  Each individual primitive is easy to exhaustively test.  Then I
assemble the lot into a function that has a dozen function calls and a dozen
lines of "glue."  The whole lot is somewhat easy to exhaustively test.  Then
I include the lookupElement function in my client program, where it takes up
the same single line of code that LOKUP originally did.  I haven't added any
complexity and in fact made it easier to understand because I no longer have
to remember what resulting indicators mean what!

>Well, Jim, as long as you're certain that you're not 
>introducing other errors by replacing a well-written 
>and well-tested opcode with an external procedure
>that likely does not face the same QA as Barbara 
>and Hans put their code through.

This argument has merit, but if you have clear requirements for your
replacement function you can perform a rigourous test regime on it before
deployment.  I know that I try to test ALL my code before it goes out the
door - it's pretty much all mission critical stuff.  Just because I
encapsulated a function doesn't make the function more mission critical than
the client programs.  Remember, smaller is easier to test!

Great thread Dan!

Buck Calabro
Aptis; Albany, NY
"Nothing is so firmly believed as
 that which we least know" -- Michel Montaigne
Visit the Midrange archives at http://www.midrange.com
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---