RE: Overloading in RPG. -- RPG400-L

James,

You are on the right track here. You just say getCusInfo(....). The dots
representing the different parameters you put into the brackets. getCusInfo
will be able to support different "signatures" which you will have to code.
Therefore if you said getCusInfo(keyedName, keyedNumber) (using Java
notation here) you would have to have something in the getCusInfo procedure
which checks for this particular signature. What this means is, if you say
getCusInfo(keyedName, Phone, CusNumber) and you haven't coded for this
signature you will get an error.

Hope that makes it clearer.

Alistair Rooney
Software Engineer
Tibbett & Britten Africa
+27 31 2047701

A lottery is just a tax on people who are bad at math



-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of James W. Kilgore
Sent: Friday, May 11, 2001 12:25 AM
To: RPG400-L@midrange.com
Subject: Re: Overloading in RPG.


Scott,

I get what you are saying, but I also understand where Albert is coming
from.

Maybe you can help get me up to speed, because I would really like to take
advantage of this.  I can see many uses for it.

First, I think that Albert (I'm not picking on you, this is just an example)
and
others have a successful paradigm that has worked for them and desire a good
example of how they can benefit from overloading.

After reading Albert's and your postings I thought of a magazine article (or
maybe a series of them) titled "The last date routines you will ever need"
or
something like that.  I remember at that time thinking they truly ARE the
last
thing I would WANT!  BTW, this was before date data types, but the whole
concept
was a whole bunch of little routines that did something with dates supported
by
another whole bunch of routines that converted your input into an agreed
upon
date format.

Under that concept, it would be normal to take your input and call one of
several
routines to convert your data to the agreed upon format then call the
routine
that actually performed the desired function.  Oh, I almost forgot, then you
called another routine to convert the results into the format you wanted to
work
with.  And if the format of your input changed, well ... go fish ;)

Now here is where I'm lacking on education.

Let's say I want to write GetCustInfo and I want to pass a name (alpha) or a
customer number (11,0S) or a phone number (also 11,0S).  I still wind up
writing,
and using within my program, GetCustInfoByName, GetCustInfoByNumber,
GetCustInfoByPhone or do I just write GetCustInfo(NAME:keyedName) or
GetCustInfo(NUMBER:keyedNumber) and GetCustInfo(PHONE,keyedPhone)?  Or can I
write GetCustInfo(keyedName) GetCustInfo(keyedNumber) and
GetCustInfo(keyedPhone)
and GetCustInfo can by divine province tell the difference?  Now each
customer
has a unique number, but I may have more than one ACME in my list.  So get
by
name has to be able to return a list of possibilities if there is more than
one
or just the info if there is only one.

Again this may be a bad example.  But a true, real world, working example
would
help a whole bunch for me.

Scott Mildenberger wrote:

> Albert,
>
> Using your example below, why should every program that needs to use
DaysDur
> have to worry about converting to a common format.  It is just extra code
> that every calling program needs that can be eliminated.

<<snip>>

>
>   At least in my mind, it would be nice that anytime
> I wanted to calculate a duration in days I just call DaysDur and pass my
> dates, no worrrying about how the date has to be formatted and doing that
> conversion.
>
> I do think overloading can be really useful in some cases, and of course
> like any tool it can be abused.
>
> Scott Mildenberger
>
> > -----Original Message-----
> > From: York, Albert [mailto:albert.york@nissan-usa.com]
> > Sent: Thursday, May 10, 2001 12:20 PM
> <<snip>>
> >
> > I would prefer to have one procedure and do any necessary
> > conversion in the
> > program.
> >
> > For example:
> >
> >       DDaysDur          PR             5I 0
> >            D CharDate1                      8A
> >            D CharDate2                      8A
> >
> >       C                   Eval      Cdate1 = Ndate1
> >       C                   Eval      Days = DaysDur(Cdate1: Cdate2)
> >

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---