RE: Runtime KLIST change?

My apologies for being so late responding to this. Have been up to my neck
in work and have been forced to wait to the weekend to respond to anything
that requires more than a few lines. 

I think that Hans covered most of this but I would like to respond.

>> are suggesting that one should not only write mystifying code, but then
hide it so it can't be found be mere programmers?

Absolutely. The principle is called encapsulation or information hiding and
has been the basis of programming almost from the beginning. Do you know how
the ILE RPG compiler calls the "C" I/O libraries? Of course not. All that is
hidden and you don't know how it does it, it just works. 

The problem is that we have been working in RPG II and RPG III for so long
with huge monolith programs with all the logic repeated in every program,
that we think that is the way you do it.

A simple example would be a push pull stack. Let's say you are writing a
bill of materials processor and realize that you need a push pull stack.
(Each level down in the bill gets pushed on to the stack and each level up
gets pulled off.)

You could code the solution one of three different ways.

1. RPG III - Create all your logic for the stack in your programs using
array and data structures and repeat this every time you need the same logic
in another program.

2. RPG IV -  Create your stack using dynamic memory allocation and pointers
in your program. As each element is added to the stack, allocate some memory
and put it into a linked list and as each element is pulled, discard the
memory. This could, also, be done using arrays and, of course, the next time
you need the same thing in another program, you repeat the same logic again.


3. ILE RPG - Build a service program containing four functions. 
                A. InitializeStack
                B. PushStack
                C. PullStack
                D. ReleaseStack

The scary one is definitely number 2. You are ending up writing all this
logic using pointers and then require another programmer to maintain it and
you end up recreating and debugging the same logic over and over again.
Instead of spending their time adding functionally to the bill of materials
process, they are trying to figure out how the stack works. 

If you take option three or, someone else has already written it, you now
longer need to know how the stack works or how it is implemented. I could
write this procedure and publish the interface and you would not have to
have any idea about how it works. You, or any other programmer following
you, would be able to focus on the bill of materials problem and not how a
push pull stack works. 

It, also, means that when I write the Push Pull Stack, I can focus on
nothing but making the Stack work correctly. I don't need to be thinking
about how a bill of materials works.

And this is exactly what we want. The more information that we can hide, the
less complexity in our programs and the easier they are going to be to write
and, most importantly, to maintain. 

Taken to the limit, this is exactly the whole idea about Java and Objects.
Everything is hidden inside of objects. You create an object called CUSTOMER
and every time you need to add a customer, or some other function required
for customers, you call a method in CUSTOMER but you have no idea how
customer works, just that it does.

The same thing is true of TCP/IP in Java. If you want to communicate to
another program using sockets, you just write a few lines of code to call a
method and everything works. You have no idea how sockets work and unless
you are interested, you don't need to know. Everything is hidden. If I have
to sit down and write sockets logic every time I need to talk to another
machine, I have a real problem.

Same thing could be said to be true of anything. If I need to convert a
quantity from cases to eaches, why should I have to write this logic over
and over again? I should be able to call a function hidden in a service
program and not spend my time trying to figure out how it works. It is again
hidden from me.

I feel strongly that if we are writing programs in ILE RPG, this is how we
should be writing them. All the main logic should be hidden in service
programs. The code calling the function should only be implementing the
logic for that function, not how to convert cases to eaches.

Ok, done ranting now. One of the things that ILE RPG does for use it forces
us to look at these kind of issues and I think that is great.   

-----Original Message-----
From: boothm@earth.goddard.edu [mailto:boothm@earth.goddard.edu]
Sent: Saturday, December 04, 1999 9:03 PM
To: RPG400-L@midrange.com
Subject: RE: Runtime KLIST change?


My gosh.  You are suggesting that one should not only write mystifying 
code, but then hide it so it can't be found be mere programmers?   Now, 
that is scary!

"never seen a piece of unmaintainable code that was written with some
kind of leading edge technology."    Let me mail  you a WSU program on 8"
floppy to look at. 

_______________________
Booth Martin
boothm@earth.goddard.edu
http://www.spy.net/~booth
_______________________




Alan Campin <Alan.Campin@CaseLogic.com>
Sent by: owner-rpg400-l@midrange.com
12/04/1999 09:39 PM
Please respond to RPG400-L

 
        To:     "'RPG400-L@midrange.com'" <RPG400-L@midrange.com>
        cc: 
        Subject:        RE: Runtime KLIST change?
...
Pointers usage, in my mind
anyway, should always be encapsulated in a function and hidden. Using
pointers in the general body of a program is scary to me and, of course,
there is always that fear that someone will misuse a powerful tool. 
...
I have never seen a piece of unmaintainable code that was written with 
some
kind of leading edge technology. Always the opposite. 2 or 3 thousand line
mainlines with the same logic repeating 10 times in 10 different versions
and one thousand line subroutines doing twenty different functions and all
doing what could have been done in a few hundred lines of code if properly
designed. Why engineer code when you can just start pounding code?
...

Now that's scary. 


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