× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.