RE: Prototyped Procedures

[James Rich <james@xxxxxxxxxxx>]

On Wed, 2 Feb 2005, Joe Pluta wrote:

> > 2) Consumers only need the prototypes. They have no business looking
> at
> > the implementation in a properly designed interface.
>
> If I'm debugging, I had better be able to see the source code of the
> modules I'm calling.

Huh??  How is this even relevant?  I keep my prototypes in separate source 
members and I can still have the debugger step into code that is kept in 
seperate members.  Separating your prototypes from the implementation 
doesn't prevent you from debugging either the caller or the callee.

> > 3) If someone forgets the proper DEFINE they get the source copied
> into
> > the program leading to all manner of peculiar behaviour:
>
> If someone forgets a semicolon in /free, they get all kinds of peculiar
> behavior.  If someone forgets the "F" in an F-spec, they get all kinds
> of peculiar behavior.

True, but why needlessly force a DEFINE on people?

> > 4) It's just plain ugly to require the consumer to decide whether they
> > want the code or not.
>
> Eye of the beholder.  Personally, I LIKE the fact that all my prototype
> includes are nicely encapsulated inside a /DEFINE PROTOTYPE and a
> /UNDEFINE PROTOYPE.
>
>
> > /copy rpgleinc,fbnmath
> > /copy rpgleinc,fbnstring
> > /copy rpgleinc,fbndate
> >
> > is much cleaner than forcing the consumer to remember to code
> > /define prototypes
> > /copy rpgleinc,fbnmath
> > /copy rpgleinc,fbnstring
> > /copy rpgleinc,fbndate
> > /undefine prototypes
>
> "much cleaner"?  How?

Cleaner because when you copy those members in, you do so to access the 
function definitions.  Requiring the additional step of DEFINE is simply 
tedious.  I already copied in the relavant definitions, and by doing so 
said "I want the function defintions in these members."  Why make me say 
it twice with a needless DEFINE?

> On the other hand, there are real reasons to use the /DEFINE PROTOTYPE
> method.  I may want to define an area in the caller and not in the
> callee.  That area may need a predefined layout, such as a data
> structure.  With the use of the /DEFINE, the source member can define
> the data structure in both places as based, but actually define data for
> it in the caller:
>
> D MyParmDS        s                   based(pMyParmDS)
>  (...) DS Subfield definitions
> D MyProcedure     PR
> D   pDS                           *
>
> /IF DEFINED(PROTOTYPE)
> DwMyParmDS         s                  like(MyParmDS)
> DpMyParmDS         s              *   inz(%addr(wMyParmDS))
> /EOF
> /ENDIF
>
> In the single include technique, I'd have to hand-code those last two
> lines.  Two lines may not be much, but it gets more involved with more
> complex structures.  Whether you like this technique or dislike it, it
> can only be done with a single include member.

I think I see your point here.  It may well be that the best current 
solution is the one you suggest.  But it appears to me that this solution 
is a work around for the lack of data type definitions in RPG (i.e. 
typedef).  But that is RPG's fault, not yours.

James Rich

It's not the software that's free; it's you.
        - billyskank on Groklaw