Re: The pulse of the Nation (Was: Please vote for Syntax check in /FREE!)

[Hans Boldt <boldt@xxxxxxxxxx>]

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