RE: No Subroutines (was Re: Debugging many subprocedures)

> From: Joe Pluta
> 
> Sorry, I misread your post; you're getting to use /free.  Good luck,
> it's actually quite fun, and the extra space makes the argument for
> procedures a bit stronger.

BTW, here's an observation: one of the problems with functions in most
other languages is that there is only one return value.  This has always
been a stupid limitation in my opinion.  I'd prefer a syntax like
"return (rc, message)".  You could even have message optional and
returned as null if not specified, but that requires multiple exit
points in a procedure which can be troublesome.  But I digress.

Because while the same is nominally true for RPG, it is easy to have
input/output parameters of any type (in fact, this is the default).  And
so in fact I can support error messages.  I can even support the concept
of catchable vs. throwable messages; by putting optional error message
fields at the end of the parameter block, I can specify whether the
caller wants to handle the error or wants it to raise an exception.

However, the ability of a procedure to modify a parameter (which is
strictly speaking a side effect) is a problem with a lot of programmers.
Personally, it's pretty ingrained in me to no have update-capable
parameters, although I do bend the rules occasionally.

How about you?  Do you use update capable parameters?  If so, is there a
way (other than the prototype itself, obviously) that you make sure the
caller knows that a given field is changed by the procedure?  The reason
I say other than the prototype is because there are performance
considerations when using VALUE and CONST.  I'm just wondering how often
people use bidirectional parms, and how they keep it straight.  It would
seem to me that this could be a possibility for nightmarish bugs.
Imagine somebody changing a pointer parameter?

Joe