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



Hans,

On Fri, 2003-10-17 at 14:50, Hans Boldt wrote:
> Joel Cochran wrote:
>
> First, just to make clear, there's been no decision yet on adding 
> procedure name overloading to the language. But we have put a bit of 
> thought into the issue.

Understood, all I ever wanted was the opportunity to vote for this
enhancement.

> I'd just like to say that, in any design of procedure name 
> overloading, the type of the return value probably should not be 
> part of the parameter signature of an overloaded name. To illustrate 
> why, consider an expression like "getMonth(x)+getMonth(y)". Does the 
> + operator work in character type or numeric type? That is, are you 
> calling the "getMonthNumberX" proc or the "getMonthStringX" proc? 
> The choice clearly affects the semantics of the expression.
> 
> At worst, allowing return values as part of the parameter signature 
> may well limit the kinds of future enhancements that could be done 
> in the language. For example, if the + operator were somehow 
> enhanced in the future, an expression "P()+Q()" that would be 
> considered unambiguous in one release might well be ambiguous in the 
> next.

Valid and well thought out, and I certainly don't want to see our
options limited in the future.  Again, I don't claim to understand the
complexities involved in making these decisions.

For the sake of argument then, let's take the return value out of the
equation, and I'll modify my example to show that there is still a valid
case for procedure overloading:

monthString = getMonth( dateField );
monthString = getMonth( timestampField );
monthString = getMonth( string );
monthString = getMonth( integer );

This is simplistic but valid.

> Cheers! Hans

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