|
Agree with you about the data encapsulation. That was a bad example :(. Yes. If all possible, parms should be passed to access the global variables (especially non-file-fields). However, if you have a proc that say return a service charge amount and to calculate this amount, it will require some fields from two or three different files, I found it usually easier and more readable if the proc just access the global variables directly. Especially if the main proc already have the records chained. Again, it all depends on the design. What I try to said in the previous reply was that there is no reason to use sub-routine. However, that doesn't mean that you should use sub-proc like sub-routine. Here is the main problem I have with sub-routine: I can't exsr from sub-proc. What should I do if my proc determined that I need to exsr to a sub-routine that set default values for some global variables? -----Original Message----- From: rpg400-l-bounces+lim.hock-chai=arch.com@xxxxxxxxxxxx [mailto:rpg400-l-bounces+lim.hock-chai=arch.com@xxxxxxxxxxxx]On Behalf Of Jon Paris Sent: Saturday, August 21, 2004 1:50 PM To: rpg400-l@xxxxxxxxxxxx More important is the reason for creating getters/setters in the first place. It is to encapsulate the data so that the _only_ way it can change is under the control of the code that "owns" that data. That is exactly the opposite of what you are doing. I try to avoid touching global data at all unless I have to. If I look at code like this: MyVar = MyProc(parm1: parm2 ...) I like to _know_ that only MyVar got changed. And to _know_ that the values in parm1 and parm2 were the controls for that process. If I see "Exsr MySubr" or "MyProc()" I know absolutely _nothing_ about what variables are modified, or what variables control the process unless I go read the code. The less code I have to waste time reading (only to find it is not relevant to the bug/update at hand) the better surely? In this case the only advantage of the subproc MyProc over the subroutine is that MyProc can define its own private variables - which can lead to less clutter in the mainline D-specs. But that's about all it buys you. The only time I touch globals is in an I/O module - and with the advent of V5R2's ability to specify a DS as the result of an I/O operation - even that is needed less often than it was. Just my 2 cents worth. Jon Paris Partner400 www.Partner400.com -- This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.
midrange.com
