Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

A tricky Question

 
Harry Singh
Ranch Hand
Posts: 124
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Pals,
What will be the putput of this code?

Now if i changed this to sumthing like this, then what will happen?

Can anyone explain the reasons behind it?
 
Alton Hernandez
Ranch Hand
Posts: 443
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Harjinder Singh:
Hi Pals,
What will be the putput of this code?

Now if i changed this to sumthing like this, then what will happen?

Can anyone explain the reasons behind it?

Hi Harjinder,
In your 1st example, the output would be "String Version" because it is that method that is most specific.
For you 2nd example, I believe you will get a compiler error because none of the methods are most specific.
From the JLS:

Let m be a name and suppose that there are two declarations of methods named m , each having n parameters. Suppose that one declaration appears within a class or interface T and that the types of the parameters are T1, . . . , Tn; suppose moreover that the other declaration appears within a class or interface U and that the types of the parameters are U1, . . . , Un. Then the method m declared in T is more specific than the method m declared in U if and only if both of the following are true: " T can be converted to U by method invocation conversion. " Tj can be converted to Uj by method invocation conversion, for all j from 1 to n.

and the null reference can always be cast to any reference type.
 
Anupreet Arora
Ranch Hand
Posts: 81
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Harjinder!
The first question will print "String Version". The second one will give a compiler error complaining of ambiguous reference.
In case of overloaded methods, when an argument can possibly be assigned to different methods according to their heirarchy of the parameter, then that method is called into play which provides the narrow most reference to the argument.
For example in your case, one parameter is of type Object and the other of String. And we know that a String is subclass of Object. So null, which normally is assignable to both Object or String, will be taken up by the method with String parameter as it is a more specific reference to null.
And if U do away with the Object and put in a StringBuffer parameter, the compiler cries foul rather than "putputting" sth, because String and StringBuffer are equally narrow in their reference to null. The compiler is unable to decide which of the two overloaded methods will take up the call.
I would suggest that to get a more clear perspective on this issue, rather than using a String or StringBuffer, create your own classes in a Single Inheritence and use their type of variables to refer to null
Sth like :

So this will SubClass Version as output, as SubClass is a narrower refernce to SuperClass
And if U have sth like the following :

This will give a compiler error.. as SubClass and SubClass2 are sibling classes and the compiler is confused between which to choose??
I hope things are clearer?
Cheers
Anupreet
 
Harry Singh
Ranch Hand
Posts: 124
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks mate,
yeps they are pretty clear now... Thanks all of you guys and i must say that Javaranch is the coolest place to be in.. i just love this place...
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic