tags:

views:

328

answers:

7

Is it possible to have two methods with the same name but different parameters and return types in Java? Seems like it would be a good way to generalize a simple getter and setter.. You can do that with constructors why not with regular methods ? for example

why not be able to do ..

int getVal() {

return int;
}

boolean getVal() {

return true;

}

setVal(int a) {
}

and

setVal(boolean a) {

}
+12  A: 

What would you expect if I called:

getVal();

with no return vaue being collected ? You have two choices - either the boolean or the integer variant. Since you can't enforce the return value to be collected, the compiler can't determine which variant to be called.

You can overload on method parameters, but not on the return types alone, since that's ambiguous (as shown above).

Brian Agnew
ideally if it's a boolean that calls it.. for example.. if (getVal == true) then it should call the getVal that returns a true.. otherwise if it's int a = getVal() it should call the one that returns an int.
Ayrad
As I've illustrated, you can't *force* a return value on this
Brian Agnew
+11  A: 

Because then the compiler would be unable to figure out:

setVal(getVal());

should it call the bool or int version?

yngvedh
if it receives a boolean as a paramter then it should use the setVal that accepts and sets a boolean
Ayrad
like when a constructor accepts different parameters but can have the same name.
Ayrad
But how would the compiler select the bool version of getVal in the first place? It clearly has two equally valid choices.
yngvedh
by the value that type that calls it.. if it's a boolean it should choose the one that returns a boolean, if it's an int for example int a = getVal() should use the getVal that returns an int
Ayrad
As Tnay points out, the compiler only considers the method name and number and type of arguments when resolving method calls.
yngvedh
Actually, it *couldn't* have figured out the int/boolean problem if there was both a `setVal(boolean)` and a `setVal(int)`. As for the String/Object situation, it could have used the same resolution rules it does when it encounters the call `foo("bar")` and there's both a `foo(String)` and a `foo(Object)` to choose between - i.e., use the most specific one.
gustafc
I think even if it would be feasible it will pose great performance degradation since JVM will have to cope with all these testings while deciding which method to call. Anyway, I think this way it force us to be more neat and responsible in designing our systems.
ante.sabo
+2  A: 

Different return types, no. But different parameter types / length, yes. That's how Java is... specification says that. They wanted to keep it simple.

Raze
Same applies for C++ too.
Raze
+7  A: 

At first glance it may seem as if there should be no reason that one should not be allowed to do this, but however think about it from the perspective of code that must call this(these) method(s), how would it know which method to invoke?

From java.sun.com

The Java programming language supports overloading methods, and Java can distinguish between methods with different method signatures. This means that methods within a class can have the same name if they have different parameter lists (there are some qualifications to this that will be discussed in the lesson titled "Interfaces and Inheritance").

Overloaded methods are differentiated by the number and the type of the arguments passed into the method.

You cannot declare more than one method with the same name and the same number and type of arguments, because the compiler cannot tell them apart.

The compiler does not consider return type when differentiating methods, so you cannot declare two methods with the same signature even if they have a different return type.

instanceofTom
There is actually a reason: covariant return types using bridge methods.
eljenso
Compiler can not. But jvm can. J
St.Shadow
+4  A: 

As far as the Java Virtual Machine is concerned, it is possible for a class to declare multiple methods with the same signature but different return types.

Only, Java as a language forbids this.

eljenso
A: 

You can declare the two setters in your case - try it.

Methods must be unique in terms of their name, and the number and type of their arguments. The return type, as well as the throws clause, do not count in terms of making a method unique (which makes sense, as they're not specified when you invoke it).

Andrzej Doyle
+3  A: 

Generally speaking - no. But if you want it very much - then YES :)) Check this great article

St.Shadow
+2 for interesting article, -1 for the *horror* of thinking people might actually do that. :-P
Andrzej Doyle
Fully agree with you. One situation when it will be *really* needed - legacy code where easily add new hook than rewrite all.
St.Shadow
Its a great find!
Raze