× 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: Jim Langston <jimlangston@xxxxxxxxxxxxxxxx>
  • Date: Thu, 10 May 2001 15:53:46 -0700
  • Organization: Pacer International

The benefit comes in from the programming side, not the service program side.

In a program now, all I have to do is Eval Duration = DaysDur(someval: 
somveval) 
not care what I am passing it, the overriding procedures would take care of it.
Once you build the service program the maintenance part is done 'til you have 
to fix them.  But, now you can call DaysDur any time you want without having to
even think about what type of parameters you are passing, it's taken care of
you, the application programmer.

Yes, this shifts the burden onto the system programmer, who writes the service
programs, and yes, they are a lot of times one in the same person.  What you 
wind up doing is investing time in your service program to save time on your
application program.

I know it may not seem like it's worth it when you're writing the service
program modules.  But after you start using them you realize you've just saved
yourself a whole ton of time in the long run, and your programmers are much
easier to maintain.

If I did this I would wind up with 4 procedures to change, but 3 of those 
procedures would call the 4th after setting up the variables correctly.

DaysDir accepts CHAR CHAR.
it converts the dates to date variables, then calls DaysDir with the date 
variables.

You find you really only have one procedure you actually have to maintain, the 
one
that is actually doing the work.  The other are finished after you get them to
pass and accept the parameters correctly.

Now, I could, if I wished, now write a DaysDur program that accepted two 
pointers.
This subprocedure would then have to look at the contents of the pointers and
determine what type of variables were passed to it.  In this Particular case it 
should be relatively easy to determine if a character string was passed to it
or a date variable and do the calculations accordingly.  This is what I meant by
the fact we could do  the same thing as overloading, although differently.  The
mechanics of overloading makes it much easier for the system programmer.

Regards,

Jim Langston

Me transmitte sursum, Caledoni!

"York, Albert" wrote:
> 
> I still don't see any benefit to overloading. It seems like an opportunity
> for confusion.
> 
> I don't see how you have simplified maintenance any. You still have 4
> subprograms to maintain.
> 
> In addition, I don't see how there would be any guarantee that these
> routines would do the same thing, just because they have the same name. As I
> understand it, they are entirely different.
> 
> 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)
> 
> Albert York
+---
| 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 ...

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.