Kurt Anderson wrote:
I just want to address the comment about output parameters being a
bad design technique. It's good design. Ok, that's my opinion.
Output parameters are passed by reference (16 bytes).
FWIW, I completely agree with you. Using parameters for output is
elegant, simple, performs well, etc.
There are times when I'll use a return value for output data...
especially when I'm writing a routine explicitly designed to be used in
an expression. For example, a routine that takes a number from 1-12,
and returns a month name January-December -- that's a good place to use
the return value.
But, when the output isn't meant to be used in an expression, I just
return a success/fail flag.
I guess it comes down to personal choice and style, so long as people
err on the side of readability. I won't say not using output
parameters is bad design, but I don't agree that using them is
either.
Amen. They're all tools in the toolbox. Understand them, and use the
right tool for the job.
I wouldn't mind hearing the justification of why using output
parameters is bad.
I've heard three arguments for this so far (I don't agree with any of them)
1) It makes it clearer which data is input and which data is output,
enforcing that input parameters are only used for input, and output
parameters are only used for output.
2) All routines should do only one thing. Since there's only one return
value, using the return value for output enforces that the routine does
only one thing. If you need to return something else, make a different
routine.
3) Modern languages, like Java, cannot return output through their
parameter list. If you want your RPG code to be modern, you shouldn't
return data through the parameter list, either.
Those are the arguments I've heard. I don't agree with them. Here are
my responses to them:
1) This argument makes a good point, however, if all input parameters
are defined with CONST or VALUE as they should be, then it should be
easy enough to see which ones are input/output without returning
everything via the return value.
The performance problems of the return value, and the awkwardness of
having to create data structures for simple things like returning two
values is a bigger and more important issue, than clearly delineating
input vs output.
2) Unfortunately, "one thing" is really hard to define in exact terms.
I don't think "one thing" was really meant to equate to "one parameter"
or "one variable".
There are certain things that are naturally computed at the same time.
For example, retrieving a customer's address... does it make sense to
CHAIN/SELECT a new record for the customer's name, then again for the
street address, and again for the city, and again for the
state/province, and again for the postal code, etc, just because you
wanted each piece of information returned separately? That's not good
for performance to re-get the record each time, plus these things will
almost always be retrieved together. What's the point of making the
caller call 5 routines instead of 1?
As soon as you return the data in a data structure to get all of the
fields at once, you've broken your own "one thing" rule. I agree that a
routine should do "one thing", but I don't agree that it should only
return one output variable. If you're going to have mutliple output
variables, what's the point of restricting to the return value?
3) All programming languages have their quirks. The best policy is to
take advantage of the best features of each, rather than restricting
yourself to only using techniques that are available in all languages.
I find it hard to believe that the way you pass parameters will make
your code more or less "modern". Instead, do what's practical in the
language you're working in, rather than making things more difficult in
the name of "being more like Java."
midrange.com
