Re: Todays WTF

Joe Pluta wrote:

Not to argue the point, but I've found a really nice use for subroutines. I
use subroutines INSIDE of procedures to break out repetitive code or simply
top keep the mainline of the procedure down when the code is complex. The
subroutines can access any of the procedure's local variables, much the same
way that methods can use private class variables.

It allows me to share variables among parts of the code without having to
explicitly pass them up and down the stack. It's a tradeoff, because if one
of the subroutines modifies the variable then it's technically a side
effect, which should be avoided, but in reality it can be a real time saver
not having to prototype a bunch of procedures that are only used in one
place.

Joe, I think you are right that subroutines in subprocedures should be considered in a different light from subroutines in the main procedure.

The problem with RPG subprocedures is that they don't support nested subprocedures. If you want to decompose the code in a subprocedure, let's call it subp, you have two options. You can use a subroutine, or you can add another subprocedure. If you add another subprocedure, let's call it subsubp, you have to expose the interface to subsubp to your entire module. If it needs to use any of your local variables, you have to pass them as parameters. If you decide to use a data structure for the local variables of subp, so you can define the prototype of subsubp using likeds, then you end up with the very strange situation of having a global data structure whose purpose is to define the private interface between subp and subsubp.

I'd say that having a subroutine access its parent subprocedure's local variables is a lesser evil.

There's one more alternative that may be the best for some situations. If subp doesn't use any global variables, then subp and subsubp can be moved to another module, where subp is exported and subsubp is not. Then the private interface between the procedures can remain private.