Re: Subroutines vs Subprocedures was RE: Indicators

On Tue, 2004-08-24 at 21:35, Tom Jedrzejewicz wrote:
> On Tue, 24 Aug 2004 17:01:07 +0000, Joel Cochran <jrc@xxxxxxxxxx> wrote:
> > 
> > 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
> 
> Cool link, great article.

Thanks!

> I concede about the global variables, although I do maintain that it
> should be avoided.  The SQL issue (you cite below) is in my view an
> implementation problem.

I hope you mean implementation by IBM?  If so, you are in the company of
a long list of people waiting for the SQL Pre-compiler to catch up to
the RPGIV compiler.  If you mean that it is a design issue, I would have
to disagree.

> My point was that SubProcedures were created to allow for
> encapsulation and other OO concepts to be implemented more easily
> using RPG, and also in a manner consistent with other languages. 
> There is no huge benefit to using them in place of EXSR other than to
> become more familiar.

Again, I disagree.  There are huge benefits to using sub-procs over
subroutines.  Basically, all the same benefits that you would have by
externalizing PLUS the ability to use global variables (in the same
*MODULE object).

1.) Local variables.  With local variables in a sub-proc, I can set
initial values and re-use field names without stepping on the toes of
the rest of the program.  Let's say I have 3 sub-procs, and each one
uses a FOR loop.  Like most programmers, I have a typical variable that
I use for looping ("i"). I can use the same variable name in all 3
sub-procs without concerning myself with their value (in other words I
don't need to clear or reset them before using them).  I can even have
different initial values in each sub-proc, and everytime I call a
sub-proc the variable is automatically re-initialized.  Basically, I can
end up with less code in the long run and focus solely on the task at
hand in that sub-proc without worrying about affecting variable in the
rest of the program.

2.) Parameter passing.  We historically think of parameter passing as
something done between programs.  With sub-procs, we can now have the
same level of control internally.  I'm sure we've all had subroutines
that expect certain variables to be set before they are called: the
problem is that there is no enforcement of these rules.  Parameter
passing to a sub-proc allows you to enforce these rules, setting the
stage for the procedure to run.

3.) Return values.  Again, we've all had subroutines whose sole job was
to do a series of calculations.  Now we can embed the process of that
evaluation into another statement, or a series of other calculations, or
what have you.

All this being said, and to tie this back to our original conversation,
there may be a need, or as I've demonstrated a requirement, to access a
global variable, but just because I do does not negate these other
benefits.  

> > 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.
> 
> Makes sense, but in that case there is little difference between a
> SubProcedure and a SR.

Assuming that I'm ONLY accessing global variables and not taking
advantage of any of the other benefits listed above, I suppose this
would be true.

> I think that winds around to where I was going.  There is very little
> functional difference between a SR and an internal SubProcedure.   The
> real value of SubProcedures is that they allow for changing the DESIGN
> of the applications to use encapsulation, OO concepts, and improving
> reusability and modularity.

I hope I've shown that there are significant functional differences.

> Back to the very start here . . . if the guy has designed his
> application already, is writing code, and is wrestling with the
> decision of whether to use SubProcedures or EXSR, he is too late and
> at that point it really doesn't matter.

Again, if we were talking about external procedures I might see your
point, but for internal purposes, given the benefits I've listed above,
if he is now writing the code, then this is the time for him to decide
between the two.

> > This is, in fact, the point of sub-procs, but not what this discussion
> > was about.
> 
> I guess I was trying to take it there . . . 

Now, if we want to move on to a discussion about modularization,
externalization, and re-use, I'm all for it, cause I think this
particular horse is dead.

Joel
http://www.rpgnext.com