Return type polymorphism
843789Jan 13 2010 — edited Jan 18 2010Return type polymorphism
Java does not allow to overloading a method with same signature, with a different return type. Actually Overloading a method with return type can be easily supported!!.
Here I am going to describe it. This seems to be supported from the very beginning of java development, but still Sun can implement this feature in next releases by using a separate compiler parameter and similarly in to JVM.
I have seen Sun justifies to not to implement this feature, as they prefer more methods with different names, in fact the overloading meant for use the same method name which does similar functionality.
How can support it?
---------------------------
Identification of method should be done from the calling portion.
if the method defined has void it should be called independently.
And when JVM sees a method preceded without assignment or comparisons, it must expect to call a method with void return type.
like
..
display();
...
When a method with return type is found, JVM should call the method with the expected return type in the context.
here are some cases.
1) if (mtd()) // in this case method with boolean return type should be called.
2) System.out.print(mtd()); // a method which returns String type should be selected.
3) mtd(); // a method with void return type should be called
4) float i = mtd(); //a method with float return type should be called, if float return type method does not exist
//then here autoatic promotion rules can be applied, means can call a int return type method also
5) System.out.print(mtd() + 2); // a method which returns numeric should be called (if int is present that should be called)
6) 5) System.out.print(mtd() * 2.5); // a method which returns numeric should be called (if float/double is present that should be called)
From all the cases there is an expected return type, and JVM would be able to call the proper method accordingly.
Usage:
-------------
Consider, A base class have a method which return void (means nothing), and in the sub class programmer want enhance the method and return some value to indicate the status of processing (think the original method throws exception while processing).
Here is simple program, which does nothing!!, to explain the advantage/usage of return type polymorphism.
abstract class acClass{
static void display(String s){
out.print(s);
}
abstract void doProcess() throws Exception;
}
public class ClassTest extends acClass {
// return type polimorphism
int doProcess(){
try {
this.doProcess();
// update the processed data and report to application
return 0;
}
catch(Exception e)
{
//update database with error and report to application
return -1;
}
}
void doProcess() throws Exception {
//Code here to process
}
public static void main(String[] args) {
//How simple can a code looks and more readable by using return type polymorphism
if (new ClassTest().doProcess() == 0) // Here doprocess() with int returm type will be called, as expected to compare with int type
{
display("Successfully processed");
}
// Also programmer free to use the base implementation directily
try{
new ClassTest().doProcess(); // Here doprocess() with void retuen type is expected to call
display("Successfully processed");
}
catch(Exception e) {
}
}
}
About myself: I am working in an MNC as a java developer, and myself feels happy when find solutions to the problems in the applications (even more, when other buddies does not able to solve it!! ? means to be an extra-ordinary), and I like to explore java in depth.
Now, why can't Sun go for retrun type polymorphism?
Any comments on the article appreciated.