× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Overloading in RPG.
  • From: "James W. Kilgore" <qappdsn@xxxxxxxxxxxxx>
  • Date: Thu, 10 May 2001 15:24:38 -0700
  • Organization: Progressive Data Systems, Inc.

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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.