Donnerstag Apr 24, 2008

Too Many Return Types

(inspired by a discussion on one of my mailing lists)

The compiler says 'No'

Thank to the overloading feature in the Java programming language, method names within a class have not to be distinct (as long as the signatures differ). Can we overload a method by changing only the return type, i.e. if there is a method, can we define another one with the same name and parameter types and order, but with a different return type? The compiler says 'No'.

   class A {
       S f( p ) { ... }
       T f( p ) { ... }   // ST, p is a parameter list
   }

This behavior is defined in the language specification [1] and, with the return type not being part of the signature, it is not a violation of our definition of overloading. Of course, the language-specification argument is only for the compiler a strong one for treating the situation in this way. For those, who sit on the other side of the code, it's more a fact than a reason.

Who you gonna call

Although we don't hold methods to be objects in the sense that they are instances of OOP classes, in our minds a method still has a type, and the most interesting properties are possessed by its input and output. Thus, if we imagine that a method is something like a function, we can write

P1 × P2 × … × PnS

as the type of the first f from the example above; the type of the second f looks similar, S is replaced by T. Let's now suppose, there is a call to f somewhere in the source, so that it's
  1. a call where the return value is thrown away, or
  2. a call where the return value is passed to a method or an operator (as an argument).
At this point we run into difficulties, for it's not always clear which f should be called (we'll see, that this holds for both cases). Since the difference lies in the method type, we must specify the type of the method we want to be called. The types behind the arrow can be derived from the call itself. This is how an overloaded method is normally chosen, but here we have to specify the return type as well.

The obvious solution is at the same time the behavior we want to have claiming return-type overloading. A call is always within a certain context, and it's the context that shall specify the return type. For a (non-overloaded) method g of the type SR (Svoid), putting a call to f into the argument place, we want the first f to be chosen. If S or T is void, case 1. specifies an f too, otherwise we don't know which f is meant.

However, there remain more situations where the context does not do the job. First of all, return-type overloading collides with parameter-type overloading (and with generic programming). Suppose there are now two methods g, one taking an S and one taking a T as an argument. Then in g(f(...)) we want the call to f to specify the context, on the other hand we want the context to specify an f.

Implicit type conversion can be treated as a kind of parameter-type overloading (e.g. a method that takes a java.lang.Object as an argument does not distinguish between all the subtypes). Sometimes we want to cast a return value. Again, we can think of a cast operator as an overloaded method.

From the existence of such cases it is apparent, that we need a special syntax that resolves ambiguity, and it's not possible to stay within the grammar of the language.

Links

About

Sun Campus Ambassador,
University of Frankfurt (Germany)

Search

Categories
Archives
« April 2014
MoDiMiDoFrSaSo
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Heute