RE: Benefits of Sub-procedures

["jt" <jt@xxxxxx>]

| -----Original Message-----
| From: rpg400-l-bounces+jt=ee.net@xxxxxxxxxxxx
| [mailto:rpg400-l-bounces+jt=ee.net@xxxxxxxxxxxx]On Behalf Of Hans Boldt

| jt wrote:
|
| > ...
| > | which returns the next
| > | available transaction number as a string. Then, the users of the
| > | procedure are spared the gory details of the actual implementation.
| >
| > What advantage does a procedure offer in this case...?
| >
| > Well, that depends...
| >
| > I try to design systems where the links between business, UI,
| program code,
| > and database are kept to a minimum (and I believe most good 400
| architects
| > do also.)  So I like a database that is updated in as minimal number of
| > programs/modules as possible...  Ideally, there would be between 1 and 3
| > places the transaction number would be incremented and updated,
| in the first
| > place.
| > ...
|
| This brings up a point I thought of after posting my rant that I
| should have mentioned: Suppose you wanted to change the way
| transaction numbers were generated. Perhaps you want numbers to be
| persistent? Perhaps you want characters other than digits in your
| transaction numbers? Whatever. Coding the new transaction
| computation within a procedure (or wrapped in a class) allows you to
| more easily change the rules without affecting the calling code,
| making maintenance easier. Yet another advantage of the procedure.
|
| > ...
| > I wish you could tutor me in Python some more!
|
| I'll defer that task to others:
| http://www.python.org/doc/current/tut/tut.html

Cheers, Hans!  And thanks for the link!

But my timing is off because I just received the post I wrote that you
replied to, and I have an application to code, and bills to pay.

I would just say that you've focused on one part of the whole.  Part-a what
I'm saying is I'm not looking at this as a "what-if", I have faced these
kinds of changes in the business.  I've done these things hundreds, if not
thousands of times, just as more-n-a few of the posters on this list have.

That's why I prefer having the logic for the transaction update in 1 to 3
places.  It's not such a big deal that it ABSOLUTELY REQUIRES procedures,
and sure doesn't require class libraries...  Not saying procedures are not
one of life's sweetest pleasures (but not seeing the value of OO, very
much).  Frankly, I believe you don't wanna admit that /FREE, at times,
requires some pretty complex coding to do simple things, the way it is
currently designed.