views:

602

answers:

5

Duplicate: http://stackoverflow.com/questions/442026/function-overloading-by-return-type


Maybe this is a very silly question but I don't understand why I can't declare two methods that have the same signature when they have different return types.

public class MyClass
{
    private double d = 0;

    public double MyMethod()
    {
        return d;
    }

    public string MyMethod()
    {
        return d.ToString();
    }
}

I get a compile error that states that the class already defines a member with the same parameter types.

(Obviously the way I'm using this in my code isn't as simple as my example code...but I think it gets the idea across.)

Am I missing something concerning OO design that makes what I'm trying to do an OOP anti-pattern? Surely the compiler should be able to determine which method I'm trying to use as long as I specifically tell it which one I want.

Given MyClass myClass = new MyClass(); I would expect the following code to work:

double d = myClass.MyMethod();
string s = myClass.MyMethod();

I would expect the following code to have problems:

var v = myClass.MyMethod();

But even in the case of var it should result in a compile error.

Can anyone see what I'm doing wrong here? I'm more than happy to be corrected. :-)

A: 

A method signature is the name and input parameters (type & order) only. The return type is not part of the signature. Thus two methods with the same name and input parameters are identical and conflict with each other.

Rex M
+6  A: 

There's nothing from stopping you from calling your method without "capturing" the return type. There's nothing from stopping you from doing this:

myClass.MyMethod();

How will the compiler know which one to call in that case?

Edit: Adding to that, in C# 3.0, when you can use var, how will the compiler know which method you're calling when you do this:

var result = myClass.MyMethod();
BFree
+10  A: 

It's because of type coercion.

Say you have the following functions:

int x(double);
float x(double);

double y = x(1.0);

Now, which of the two prototypes should you call, especially if they do two totally different things?

Basically, a decision was made early on in the language design to only use the function name and arguments to decide which actual function gets called, and we're stuck with that until a new standard arrives.

Now, you've tagged your question C# but I see nothing wrong with designing a language that can do what you suggest. One possibility would be to flag as an error any ambiguous commands like above and force the user to specify which should be called, such as with casting:

int x(double);
float x(double);
double y = (float)(x(1.0));    // overload casting
double y = float:x(1.0);       // or use new syntax (looks nicer, IMNSHO)

This could allow the compiler to choose the right version. This would even work for some issues that other answers have raised. You could turn the ambiguous:

System.out.Println(myClass.MyMethod());

into the specific:

System.out.Println(string:myClass.MyMethod());

This may be possible to get added to C# if it's not too far into a standards process (and Microsoft will listen) but I don't think much of your chances getting it added to C or C++ without an awfully large amount of effort. Maybe doing it as an extension to gcc would be easier.

paxdiablo
harpo
A: 

What, if any, variable you're assigning the method to can't inform the compiler which method to use. Imagine:

String message = "Result = " + myClass.MyMethod();

Edmund
+1  A: 

Because the return type isn't all that important when calling a method. It would lead to ambiguity in many cases to have methods only differing by return type. You might not store the result in a variable at all, or do something like this:

System.out.Println(myClass.MyMethod());

The compiler would have no way to figure out, which of the methods you wanted to call.

sth