Sounds like we need sub proc overloading in RPG :-) I'd vote for it if put
on a ballot!
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [
mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Joe Pluta
Sent: Tuesday, June 19, 2007 10:42 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: Adding parameters to procedures
From: David Foxwell
But I need some more arguments.
David, the whole concept of using data structures as parameters is not
inherently a bad one. In fact, it's used quite regularly by APIs in most
operating systems. The biggest benefit is that the data structure is
typically language independent: you have binary fields for numbers and
character fields for strings and just about any language can set up
contiguous chunks of data for these sorts of things.
The other nice thing is that they tend to reduce the complexity of transport
when you have to move data from one operating environment to another (either
via a queuing mechanism or a communications protocol such as HTTP).
So, I use data structures all the time, but typically only if I am either
crossing a language boundary (such as from Java to an ILE language) or when
I am sending data from one machine to another or from one process to another
on the same machine.
Because other than that, all of the issues Scott brings up come into play,
the most important of which to my mind is the loss of prototyping. I think
prototyping (and even more importantly the ability to tell the compiler to
convert between types for you) is a very powerful feature of ILE RPG. It
removes a lot of EVAL statements and even a lot of work variables.
I do have one caveat about the whole optional parameter issue, though, that
data structures does get around. While optional parameters are a seemingly
good thing, the problem is that typically as a function gets past a certain
level of complexity, the permutations of optional parameters gets to be
quite large and unwieldy, and you can end up with lots of *OMITs in your
procedure calls.
Not only that, but if you add all new parameters to the end of your
parameter list, parameters that relate to one another won't remain grouped
together. For example, you might have three groups of parameters, one
required and two optional. The required parameters go first followed by the
two groups of optional parameters. If you're adding a parameter to the
required parameters, where do you add it? At the end of the list of
parameters? If so, then it no longer sits with the other required
parameters (and it suddenly requires a whole bunch of *OMITs on every call
that uses that parameter).
On the other hand, if you put it at the end of the required parameters but
before the optional parameters, then you have to modify every call to the
procedure, which is even more work than a simple recompile.
Whereas, with a data structure you can add the parameter wherever you want
and just recompile everything. Only the programs that need that parameter
will fill it in, and nobody cares about where the parameters are. And for
those that are truly worried about not passing the right parameter
structure, you can include a constant in the data structure that identifies
the version of the data structure and have the called procedure check that
constant -- in that case, the called procedure can even support multiple
versions of callers by reformatting old versions to the new version.
The point is that it's not always a simple black/white proposition. You
have to carefully weigh your business needs.
Joe
midrange.com
