|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.