× 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.



I started a new thread  on this. This may get quite long (I hope not). After my 
post a lot of good points have been brought forward.
But I have my doubts about the usefulness of this at the moment. I hope I can 
make it clear.

So, starting with some quotes, taken randomly from previous posts:

I wrote:
>Just some thoughts on this:
>How are you certain that this (overloaded) procedure getName will return the 
>correct name? If two procedures expect a numeric value >and you pass a numeric 
>value,  will the first procedure not accept the "call" and return its found 
>name? the similar problem applies to >character  values. Just wondering.

Buck wrote:
>Hi Carel!  Great question!  In my quick typing, I hadn't thought to include 
>the details: sorry.  I would expect the compiler to match the >parameter size 
>and type to locate the proper procedure.  So, the getName in the vendor 
>service program expects a 5/0 number, the >getName in the G/L module expects a 
>12/0 number and the getName procedure in the Inventory module expects a 10 
>character >parameter.  I hope that helps explain what I was thinking about.

>And yes, I realise that it is very possible that ther would STILL be a problem 
>if the Customer number, Item number and Vendor >numbers were all numeric 5/0.  
>How would the overloading work then?  It wouldn't.  But I was just trying to 
>show that the concept of >overloading procedures actually can apply to real 
>world business needs, and is not just a topic for lectures at university.

Aaron wrote:
>Overloading would almost need to have custom data typing coupled with it to 
>make it extremely useful.  So I could pass in an object >called GLName and it 
>would know based on the object type to look in the GL file for the name.

Raul wrote:
>*UDTs*  It will be nice if RPG could use the User_defined Data Types. This way 
>you can have the compiler check and warn you if >you try to compare the 
>customer number with the item number, or if you try to compare Dolar and 
>Guaranies.   

Joel wrote:
>I showed a perfectly legitimate and easy to understand example considering 
>dates:
>
>monthString = getMonth( dateField );
>monthString = getMonth( timestampField );
>monthNumber = getMonth( dateField );
>monthNumber = getMonth( timestampField );
>
>Based on name, parameter list, and return value there are FOUR distinct 
>signatures here.  To implement this using current >technologies you would need 
>four distinct procedures:
>monthString = getMonthStringFromDate( dateField );
>monthString = getMonthStringFromTimestamp( timestampField );
>monthNumber = getMonthNumberFromDate( dateField );
>monthNumber = getMonthNumberFromTimestamp( timestampField );

Based on same books on java I have read, overloading is having defined multiple 
procedures with the same name, each receiving 0, 1 or more parameters and not 
necessarily of the same data type(s). Those procedures are always within the 
same object/class. I hope this is the correct concept.

In the matter of RPG I may see a function of overloading procedures in 
retrieving a record via a service programme, in which each procedure (with 
different parameters) reads from a different LF on that file. Procedure names 
would have proper names like GetItem, GetCustumer. I do not like having to 
retrieve one single value this way (not like the get- and set-functions in the 
EJB-standard): there are some exceptions, of course.

To extend on Joel's example: you can also define the procedure:
monthString = getMonth( );
monthNumber = getMonth( );

This requires the return of a default value, based either on job date or on 
system date. That is a business rule, set by the user. It should not be 
hardcoded within the procedure. I think, this is an (important) issue, too. 

How are you going to prototype those procedures? Are the parameters passed by 
reference or by value? The data types on the parm list are already defined. But 
the programme at run-time (not the compiler) has to determine which procedure 
to execute. And with two different data types for the return variable you may 
get problems. What will the programme check first: the incoming parms or the 
return parm? When will the check on the return parm be resolved: at the call or 
at the end of the procedure?

I know these are technical questions, to which the compiler team has to find 
the answer, and we, programmers, should not be bothered with. Some of us only 
hope it will be possible, as it is possible in some OO-languages (and I do not 
think the difference between OO and procedural languages is an issue here). 

But then, I would have thought there was a (limited) way of overloading in RPG: 
using *OMIT and *NOPASS on the prototype and checking with %PARMS and the 
inbound CEE-API's within the procedure.

Joel also wrote:
>You say this doesn't show a business case?  In all four of these procedures 
>the logic is essentially identical, so what you are
>suggesting is that having four copies of the same essential logic is somehow 
>better than having a single set of logic with four entry
>methods.  From a maintenance standpoint I'd rather have one piece of code to 
>maintain rather than four.  

I do not agree with you here: jt is right when he states overloading is not a 
business case; it is a case of development, design, coding.
And I think you contradict yourself or changed the argument: either you define 
4 prototypes and 1 procedure with 4 PI to receive the parms, or you defined 4 
prototypes and 4 procedures to deal with the incoming parms? The samples of 
java code I saw some years ago, using overloading, had multiple procedures with 
the same name and different PI's.

Regards,
Carel Teijgeler.

P.S.
Buck, "Groetjes" is correct.






As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.