Re: help with compiler directives.

Hello Gary,

You wrote:
>I don't agree with your assessment.

That's OK.  I don't care, but I did bother to refute your statements
below ...

>While unused prototypes don't occupy program object space, they do
>occupy space.

Only in the source (unless you like DBGVIEW(*LIST))

>Here's what I consider the advantages...

>1) By Defining the prototypes you want to use, you make clear the
>intent.

Rubbish.  Grouping the prototypes into separate members by classification
(i.e., string stuff, maths stuff, date stuff, etc.) is far more obvious
in intent.  If I code:
        /copy rpgleinc,fbnstring
it is obvious that I am intending to use string functions.  No one should
care that I'm using toUnicode(), getSoundex(), and getDifference() but
not using any of the sixty other functions in FBNSTRING. (Well, a
maintenance programmer might care which ones I'm using but they can see
that from the function calls.)  Why complicate the source with a plethora
of /define statements?

Also, if I use one string fuction then I am quite likely to use more than
one and I'd rather simply include the STRING copy member and have all the
procedures available to me than have to /define some magic incantation in
order to use a given procedure.

>2) Copying 1000 prototypes when you only need 2, in my opinion,
>increases the complexity with respect to debug. There's a lot of unused
>CRAP there when you copy all the unnecessary prototypes.

Rubbish.  Prototypes are completely unnecessary in debug since the
compiler has already determined if they match.  The PI is important in
debug.  In the source view you only see the /copy line, not the contents
so they don't get in the way there.  Switching to the *COPY view as
needed and then back to *SOURCE view solves any problem with respect to
"unused CRAP".

Except, if I recall correctly, you promote putting PR and PI in the same
source member and using conditional compiler statements to control
whether only the PR is included (for the user) or whether both PR and PI
are included (for the implementor).  I've seen articles by someone in
News/400 (I think it's you) promoting that approach which I've always
thought to be inane for a number of reasons.

If that is indeed what you do, then I can understand why you would find
lots of clutter in your debug view without conditional compile
statements.  But you would only get that 'benefit' in *LIST view, using
*SOURCE or *COPY views would still expose the clutter.

>I could probably name some more, but I've got to head out to the office
>about now!

The only advantage I can see to your preference is that compiles might
run marginally faster since conditional directives can cause the compiler
to skip source therefore there is less source to parse.  Big deal,
compiles on RISC boxes are so fast it doesn't matter (and since I didn't
see any /EOF in the original example the compiler will parse all the
source lines anyway -- looking for the closing /endif).

Regards,
Simon Coulter.

--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists
   http://www.flybynight.com.au/

   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------