Re: Externalising opcodes (was: Converting to upper case)

["paul cunnane" <paul@xxxxxxxxxxx>]

Excellent points Buck, I agree 110%.  I'm willing to bet that this approach
produces some of the most bug-free code any of us is likely to encounter.

--
Paul

----- Original Message -----
From: Buck Calabro <buck.calabro@aptissoftware.com>
To: <rpg400-l@midrange.com>
Sent: Wednesday, December 20, 2000 6:33 PM
Subject: Externalising opcodes (was: Converting to upper case)


> 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

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