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

["Steve Richter" <srichter@xxxxxxxxxxxxx>]

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Hans Boldt
Sent: Friday, October 17, 2003 10:51 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: The pulse of the Nation (Was: Please vote for Syntax check
in /FREE!)


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 );

good examples, Joel!

Hans replied:
>
>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.

In this case the compiler's response is that operator+ is ambiguous. To
clear up the ambiguity, the programmer could be allowed to specify the
return type, that is the full signature of the function:
     <char>getMonth(x) + <char>getMonth(y)

after all, if the proc can only be overloaded based on its arguments, the
overloaded proc will not be able to participate in the example expression:
   getMonth(x:CharRtnFld) + getMonth(y:CharRtnFld) ;
     ( error: presumably, getMonth(...) doesnt return anything )

Hans continues:
>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.

Thats sounds like a stretch. But if there could be such a problem and shops
dont want to deal with it, then the shops should not use the feature.

-Steve