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



Hey Buck,

Nice little excercise here. mind if I chip in?

On Wed, 2003-10-15 at 19:48, 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.

Just MHO, but this is not exactly what procedure overloading is for. 
These are very specific examples.  I think they could be solved if we
had qualified procedure names in conjunction with overloading:
name = VendorSRVPGM.getName( vendorNumber );
name = InventorySRVPGM.getName( keyValue );
etc.

For plain ole overloading, how about we start with something more
generic, like getMonthName().  It is perfectly reasonable to get the
month name from either a date or a timestamp, not to mention all the
different numeric and character methods of storing dates.  Procedure
overloading would allow me to write use the same procedure name for the
two different variable types:

monthName = getMonthName( myDate );
monthName = getMonthName( myTimestamp );

Furthermore, I should be able to have varying return types so that I
could get either the monthName or the monthNumber:

monthName = getMonthName( myDate );
monthName = getMonthName( myTimestamp );
monthNumber = getMonthName( myDate );
monthNumber = getMonthName( myTimestamp );

I think what we would end up with, by necessity, is true procedure
signatures based on the (possibly-qualified)name, parameters, and return
value.  You can only have one signature that accepts two strings, but
one procedure could accept a string and a numeric and one could accept a
numeric and a string.

I'm not sure you'd want to get too specific with this, like matching the
exact length of fields and such, because then you have to deal with
Value and Const, but at least generic classes like string, int, decimal,
date, and timestamp would be sufficient.


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

Absolutely, this is a very powerful tool: flexible and sensible.  I know
you know all this already, this is just for the sake of discussion.

> Groetjes!  (I hope I got that right)
>   --buck

Joel
http://www.rpgnext.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.