Re: Subroutines vs Subprocedures was RE: Indicators

On Tue, 2004-08-24 at 16:00, Tom Jedrzejewicz wrote:
> Actually, it is not good practice for a SubProcedure to access global
> variables.  SubProcedures were added to RPG as part of the ILE, in
> order to allow for modular / object-oriented programming. 
> SubProcedures should be standalone; any information should be passed
> in or obtained independently by the SubProcedure.  These practices
> come from the C++ ; the concept is called "encapsulation".
> 
> --> http://www.research.att.com/~bs/glossary.html

Encapsulation is a great idea when applied properly.  And this article
should prove I think this can be done in RPG:

http://www.midrangeserver.com/fhg/fhg072104-story01.html

However, there is nothing wrong with internal sub-procedures accessing
global program variables.  You are trying to apply a C++ OO standard to
a procedural language, and frankly it just doesn't follow.  Remember we
are talking about sub-procs WITHIN a program here, not in another
*MODULE.  As such, you may find that you are required to use global
variables.  

Take embedded SQL for example: try putting an SQL statement in a
sub-procedure that uses a local variable.  It just isn't happening.  And
as others pointed out, the fields from a file defined in an 'F' spec are
global without question.  I like to "encapsulate" my screen access for
standard file maintenance in sub-procedures, but this means the screen
variables (and the file variables) are global.  

Does this mean that as a design feature I should try these modular
techniques?  In my experience they work quite well, but I have no choice
BUT to use global variables, and no I can't redesign them so that I pass
everything in, it defeats the purpose of modularizing these particular
features. 

> Certainly you can make it work, but that is at the expense of
> re-usability and modularity.  If a sub-procedure requires global
> variables, then it can only be used by programs which have those
> global variables.

Again, and this may be where the confusion is, we are talking about
INTERNAL procedures instead of sub routines.  There is no such thing as
an external sub-routine, so those two items don't compare.

> This distinction is clearest (and most necessary) for things like Mr.
> Cozzi's toolset (xRPG?) and the CGIDEV2 service program.  The
> SubProcedures can assume nothing about the calling program.  But it is
> very relevant in the "custom" world as well.

Right, and they don't.

> How often have you had to bend over backwards to re-use a subroutine
> because of all of the "setup" work required.  If the SR were a
> properly isolated SubProcedure, the re-use is much easier.

This is, in fact, the point of sub-procs, but not what this discussion
was about.

Joel
http://www.rpgnext.com