Alan Cassidy wrote:
There are hordes of RPG programmers out there who would use it if it were
offered as "RPG". Even API's are new to most of them, I think, in their daily
work. But if it were "part of the language" it would be a more "natural"
assimilation for them, and it would be easier for them to catch on to, and a lot
more of them would do it. And that could have a multiplier effect with the rest
of them too...
<<
Alan, I agree. Your point is right on, and that's why APIs exist--the feature
isn't directly in the language so just call the API. If IBM implements it
natively in RPG IV, move over to the native functionality if necessary. Most
often, they're using the same API under the covers as you are, so the only
difference may be some subtle syntax.
In the C++ world, it is painless to code a class that encapsulates an API or
some routine into what is effectively an function call.
But if you think about it, that's what I did with RPG xTools. What to create a
user space? Use the crtusrspace('QGPL/MYSTUFF') and you're done. Would
%crtus('QGPL/MYSTUFF') be any better, easier? No but it would be "included" and
I get that.
But why not just write your own wrapper for routines that don't exist as native
RPG functions and then beat up on IBM to make subprocedure calls faster and
parameter passing more efficient (so your stuff runs faster). For example, ask
them for inLining capabilities, and so on.
I guess there's the programmer that uses what they have in the language and only
what they have in the language, and then there are those who write code that is
extendable, flexible and effectively more powerful.
Let's look at %TRIM's 2nd parameter. Barbara said it got the most votes over
everything else... and yet, %CHECK and %CHECKR where already in the language and
giving RPG IV programmers the ability to write their own TRIM subprocedure,
something like:
P myTrimR B
D myTrimR PI
D input
D trimChars
// whatever
/free
newLen = %checkr(trimChars: input);
return %subst(input:1: newLen);
/end-free
So in two lines of code you get similar results. But you have to write a half
dozen extra lines of subprocedure code to make it a subprocedure.
The problem with these types of enhancements is they encourage programmers not
to think creatively. Why didn't the people voting for this feature (an I may
have been one of them) simply think creatively and write their own subprocedure
simply write two lines of code instead of one?
I find writing subprocedures to be like exorcising. The more you do it, the
better you get at other things.
-Bob
midrange.com
