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



Joel Cochran wrote:
... The personal slight aside, 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 );

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

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.


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.

Cheers! Hans



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.