RE: Prototyped Procedures -- RPG400-L

Simon,

1) I agree.  If I am developing a set of API's for use for customers I probably 
wouldn't want customers getting their hands on the source code. 

2) Same as number 1 I think.

3) a.  True, but not much different than not correctly typing the name, or 
forgetting the prototype entirely, when using separate source members.

   b.  I'm not following you on this one.  How would it result in duplicate, or 
clumsy bindings?

   c.  I always thought service programs were for separating function not 
source.  Although it is a natural byproduct.  If source separation is the goal 
then this would apply to modules as well.

4)  I'm not buying this one.  At least not yet.  Isn't the consumer already 
making the decision on what code they need by determining to use a procedure?  
It seems to me that the decision is made at that point on what code is needed.  
The only thing left is to include only the code necessary or everything from a 
/COPY member.

    There is a 'not defined' condition around the code to prevent it from being 
included when only the prototype is requested.

5)  Same as #4.  The consumer has already made a decision on what functions to 
use by coding the procedure in their program.  I don't agree with the don't 
make them decide which ones to use argument.

    In your example of a group of date functions I might agree with you.  On 
the other hand we have a date program with many date routines.  I have seen 
numerous programs that only use one or possibly two of the routines.  There are 
some that use more but the norm is that between one and three routines will be 
used.


One of the reasons I asked the question is your point on aesthetics.  I have 
been wondering about the developer who has to follow behind me and how others 
in the shop will handle this concept when trying to use this method of 
prototyping.  I comment each define individually to identify exactly what is 
being imported which should help.

>From the responses so far it seems the main objection has come from those 
>developing software for sale and revolves around allowing consumers to see 
>proprietary source code.  A valid point for them but I don't think so for 
>those who develop in-house.

Rick

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Simon Coulter
Sent: Wednesday, February 02, 2005 10:15 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Prototyped Procedures



On 03/02/2005, at 2:47 AM, <Rick.Chevalier@xxxxxxxxxxxxxxx> wrote:

> As a longtime no /copy bigot I'm still coming to terms with using
> /copy (or /include) for prototypes.  I have used the method Joe
> describes (at least I think it's the same) and I don't see the
> difference between that and a separate copybook other than using
> /define statements.  I actually kind of like that because then I know
> exactly what is being copied.

Bad idea for a number of reasons.

1) The only reason you get away with it is because the code is
in-house. If you were developing software for resale you would have to
provide the prototypes but probably would not want to provide the code.
You would have to separate the two.

2) Consumers only need the prototypes. They have no business looking at
the implementation in a properly designed interface. Your method allows
them to see the guts and possibly make coding decisions based on "how
it works now".

3) If someone forgets the proper DEFINE they get the source copied into
the program leading to all manner of peculiar behaviour:
        a) Errors due to missing prototypes
        b) Can result in duplicate definitions and clumsy binding
        c) Defeats the point of separating the code into a service program

4) It's just plain ugly to require the consumer to decide whether they
want the code or not. It would be marginally better if you put the
define around the code rather than the prototypes. That way the default
behaviour is to include the prototypes which is what most consumers
would want.

/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

> /IF prototypename
> d Proc       pr
> d  parm1                 1a
> d  parm2                 10i 0
> /ENDIF

5) Having a separate define for each prototype name is even uglier. Why
force the consumer to decide which functions they need? If they need
one date function they will probably need many of them. Including
unused prototypes only slows the compile down a tiny fraction. It has
no effect of the compiled object.

/define getdayname
/define getmonthname
/define getdayofweek
/define getdatedifference
/copy rpgleinc,fbndate

is really ugly. And I have to add a new define every time I want to use
a new function. Urrk! Just let them include the copy member containing
all the prototypes.

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                                   \ /
                                                              X
                  ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------

Privileged and Confidential.  This e-mail, and any attachments there to, is 
intended only for use by the addressee(s) named herein and may contain legally 
privileged or confidential information.  If you have received this e-mail in 
error, please notify me immediately by a return e-mail and delete this e-mail.  
You are hereby notified that any dissemination, distribution or copying of this 
e-mail and/or any attachments thereto, is strictly prohibited.