RE: CL pgm and pointer variables

> From: Hans Boldt
>
> The functionality offered by the system API's can certainly be used
> in the construction of higher-level services useful to application
> programmers. But application programmers really shouldn't have to
> deal directly with the system API's, IMO.
(...)
> I suppose I view the issue in stark black and white terms: If you
> need to use pointers, you're doing "systems programming". If you are
> doing "applications programming", you shouldn't have to use pointers.

Okay, who slipped something in my coffee?  This is the second time in recent
history that I completely agree with Hans <LOL!>

Seriously, though, I agree with Hans for a couple of reaons.

First, pointers are tricky things, subtle and quick to deceive.  It is very
easy to make a simple mistake with a pointer that breaks things in a
non-obvious way.  Unlike most KLL language constructs, pointers can cause
errors that crop up many instructions later in ways that are very difficult
to discern.  Back in the days when I was doing assembly language
programming, sometimes the only way to find an error was to put a hardware
trace on a specific address; that's the level you get to with pointers.

Second, APIs are not easy to program.  Even using an example AND the
documentation, it's not always clear that changing something in one part of
the data structure requires a corresponding change elsewhere.  Epecially
when your example is written poorly - say by using a hardcoded value where
it should be using a %len.  This is a prime way to introduce some seriously
nasty bugs.

Finally, with the advent of service programs, application programmers should
not have to do this anymore.  Unless you're the proverbial one-man shop, you
should be able to delegate the load, having one or two people focusing on
wrappering the APIs within an easily callable interface that can then be
used by your application programmers.  This is the essence of OO programming
as well - there are class creators and class consumers.  Class consumers are
your application programmers, and for the most part they don't have to worry
so much about the intricacies of polymorphism, multithreading and garbage
collection.  That's for the class creators, who are more like compiler
writers since they are in essence adding new "opcodes" to the corporate
"language" that will be used by the class consumers.

So, pointers should be relegated to API programming for the most part
(although they can do a couple of other neat things when used properly).
And API programming should be limited to service programs (or in some cases,
bound modules) written by API specialists to be used by application
programmers.  By having your API programming isolated into small, caerfully
debugged modules, you limit the exposure that the power of pointers brings
to RPG.

JMHO.

Joe