Overloading question
edi
public class ClassOvr {
public void Pr(int i){
System.out.println("(int i)");
}
public static void main(String[] args) {
DerPr d= new DerPr();
int i=5;
d.Pr(i);//Error: Pr is ambiguous
}
class DerPr extends ClassOvr{
public void Pr(double d){
System.out.println("(double d)");
}
}
Why have I got this error?I want to call method Pr(int i) which is
derived from the base class.
Thanks.
SPG
news:1110195599....@f14g2000cwb.googlegroups.com...
this is because the param 'i' could be a double or int.. IE: could be cast
up to a double or left as an int.
To ensure you call the int version do this:
int i=5;
d.Pr((int)i);
SPG
Thomas G. Marshall
Compiles and runs fine for me on JDK 1.5! I don't believe there is a
problem with this in prior versions either.
--
Onedoctortoanother:"Ifthisismyrectalthermometer,wherethehell'smypen???"
Thomas G. Marshall
HUH??????????? What on earth are you talking about???? It is already an
int!!!
This code compiles and runs fine on java 5.
--
Onedoctortoanother:"Ifthisismyrectalthermometer,wherethehell'smypen???"
edi
John C. Bollinger
Your code is missing a closing } at the end of ClassOvr.main(), which
makes me believe you have cut up the real code and not tested the
example. After I added the bracket, the code compiled and ran fine for
me (it printed "(int i)"), which is exactly what I expected.
--
John Bollinger
jobo...@indiana.edu
Thomas G. Marshall
> edi wrote:
>
>> I have the following situation:
>>
>> public class ClassOvr {
>> public void Pr(int i){
>> System.out.println("(int i)");
>> }
>> public static void main(String[] args) {
>> DerPr d= new DerPr();
>> int i=5;
>> d.Pr(i);//Error: Pr is ambiguous
>> }
>>
>> class DerPr extends ClassOvr{
>> public void Pr(double d){
>> System.out.println("(double d)");
>> }
>> }
>>
>> Why have I got this error?I want to call method Pr(int i) which is
>> derived from the base class.
>
> Your code is missing a closing } at the end of ClassOvr.main(), which
> makes me believe you have cut up the real code and not tested the
> example.
That was my suspicion as well.
> After I added the bracket, the code compiled and ran fine
> for me (it printed "(int i)"), which is exactly what I expected.
--
"It's easier to be terrified by an enemy you admire."
-Thufir Hawat, Mentat and Master of Assassins to House Atreides
SPG
"Thomas G. Marshall" <tgm2tothe...@replacetextwithnumber.hotmail.com>
wrote in message news:83_Wd.45423$f%5.30047@trndny03...
That spews like crazy! But who cares about J++???
Sorry for misleading...
Thomas G. Marshall
I find it amazing that even J++ would have trouble with this. Seems to me
that it is a fundamental overloading that is broken. Maybe you're getting a
lot of /other/ errors? /That/'s fairly likely.
--
"Gentlemen, you can't fight in here! This is the War Room!"
SPG
"Thomas G. Marshall" <tgm2tothe...@replacetextwithnumber.hotmail.com>
wrote in message news:hw%Wd.50280$s16.17686@trndny02...
Once it has gone up the spout, you need to reboot the IDE!
Just restarted the IDE, cut an pasted, fixed the missing brace and all was
well..
What a crock!!!! I wish the bosses would splash out on JBuilder for me! :(
edi
public class ClassOvr {
public void Pr(int i){
System.out.println("(int i)");
}
public static void main(String[] args) {
DerPr d= new DerPr();
int i=5;
}
}
class DerPr extends ClassOvr{
public void Pr(double d){
System.out.println("(double d)");
}
}
But I have the error again.
Chris Uppal
> Both Pr methods are accessible and applicable, so the
> question is whether one of them is more specific than the
> other. The one in DerPr cannot be the more specific, because
> double cannot be converted to int by method invocation
> conversion. The one in ClassOvr cannot be the more specific,
> because ClassOvr cannot be converted to DerPr by method
> invocation conversion.
I don't agree. There are two methods available, one with name+signature
void Pr(double)
and one with signature
void Pr(int)
The first is native to DerPr, the second is inherited from ClassOvr, but both
are available via a reference of type DerPr.
So it should be legal (and is according to my compiler, 1.4.2 or 1.5.0).
-- chris
Chris Uppal
> I don't agree.
Sorry, please ignore that. I pressed send by mistake.
I was in the middle of a re-write claiming that the JLS is buggy (which I
believe to be true), but I've just discovered another way that javac's failing
to respect the JLS which doesn't fit with the buggy-JLS hypothesis.
More later... ;-)
-- chris
Mike Schilling
"Chris Uppal" <chris...@metagnostic.REMOVE-THIS.org> wrote in message
news:422ce74d$0$38040$bed6...@news.gradwell.net...
The question, I think, is how to interpret the following sentence: (from JLS
15.12.2.2)
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.
What does "appears within" mean? To me (and, I think, Patricia) it means
that the methods are *declared* within the types T and U respectively. The
JLS goes on to say:
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.
A method is said to be maximally specific for a method invocation if it is
applicable and accessible and there is no other applicable and accessible
method that is more specific.
If T is ClassOvr and U is DerPr, there is no maximally specific method, and
the call should be ambiguous On the other hand, if "appears within" means
"is available to a reference of", as you suggest, so T and U are both DerPr,
I don't see how T and U can ever differ, making me wonder why the JLS
misleadingly refers to them by different names.
Mike Schilling
One more data point: jikes compiles it successfully too.
Thomas G. Marshall
The reason this works is that double is not a more specific version of an
int. They are both different primitives, and share no hierarchy whatsoever.
There /are/ conversion rules that take place, but the minute you started
quoting from the JLS "T is more specific", then you were referring to
objects, not primitives.
--
"His name was Robert Paulson. His name was Robert Paulson. His name was
Robert Paulson..."
Patricia Shanahan
That is exactly my reasoning.
Also, consider the intent: "The informal intuition is that
one method declaration is more specific than another if any
invocation handled by the first method could be passed on to
the other one without a compile-time type error."
public class ClassOvr {
public void Pr(int i){
System.out.println("(int i)");
}
public static void main(String[] args) {
DerPr d= new DerPr();
int i=5;
d.Pr(i);//Error: Pr is ambiguous.....
}
}
class DerPr extends ClassOvr{
public void Pr(double d){
System.out.println("(double d)");
}
}
The first Pr declaration cannot handle "new DerPr().Pr(3.5)"
because double is not invocation-convertible to int.
The second Pr declaration cannot handle "new
ClassOvr().Pr(3)" because it is not a member of ClassOvr.
Patricia
Mike Schilling
"Thomas G. Marshall" <tgm2tothe...@replacetextwithnumber.hotmail.com>
wrote in message news:TF6Xd.48451$ya6.44238@trndny01...
No, I wasn't. If you look at the JLS, you'll se that method specificity is
described in terms of type conversion, and the implicit conversion from int
to douible is treated precisely like the implicit conversion from String to
Object.
If you like, modify the file in question to:
public class ClassOvr2 {
public void Pr(String s){
System.out.println("(String s)");
}
public static void main(String[] args) {
DerPr d= new DerPr();
d.Pr("abc");//Error: Pr is ambiguous.....
}
}
class DerPr extends ClassOvr{
public void Pr(Object o){
System.out.println("(Object o)");
}
}
The same conclusion applies: the JLS appears (to me) to define the call as
ambiguous, but both javac and jikes like it just fine.
Thomas G. Marshall
> "Thomas G. Marshall"
> <tgm2tothe...@replacetextwithnumber.hotmail.com> wrote in
> message news:TF6Xd.48451$ya6.44238@trndny01...
>> Mike Schilling coughed up:
...[rip]...
> [...] and the
> implicit conversion from int to douible is treated precisely like the
> implicit conversion from String to Object.
No, they're not, but I'm re-scrutinizing the jls and I think that you're
right in that there is a vagary here that is disturbing.
This phrasing you quoted from the JLS bugs me no end:
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.
[...]
Does "method conversion" include conversion from int to double, or was that
meant entirely as a statement concerning objects. I'm really not sure. I
think that the jls examples were all objects.
...[rip]...
--
"I don't want FOP, God dammit! I'm a DAPPER DAN MAN!"
Patricia Shanahan
> Does "method conversion" include conversion from int to
> double, or was that meant entirely as a statement
> concerning objects. I'm really not sure. I think that
> the jls examples were all objects.
>
> ....[rip]...
>
>
I think shortening "method invocation conversion" to "method
conversion" may be a bit confusing, because it sounds like
something one would only do to methods.
"Method invocation conversion" is defined in the JLS "5.3
Method Invocation Conversion" at
http://java.sun.com/docs/books/jls/second_edition/html/conversions.doc.html#12687.
It is specified as including "widening primitive
conversion", and one of the forms of widening primitive
conversion is int to long, float, or double.
Patricia
Andrea Desole
>
> I would think so too, but it compiles for me using 1.4.2_05 .
Same for me. Java 1.4.2_06 on Linux. Compiles and runs correctly.
Chris Uppal
> That is exactly my reasoning.
I agree that that's what the JLS2 says. However, as I said last night, I think
it's buggy.
I'm going to change the running example slightly (sorry, but I found the
earlier example's odd class and method names much too confusing, and anyway I
want to introduce a small change). Consider this:
=================================
class A { }
class B extends A { }
class Base
{
void method(B b) { System.out.println("Base(B)"); }
}
class Mid
extends Base
{
void method(A a) { System.out.println("Derived(A)"); }
}
class Derived extends Mid { }
public class Test
{
public static void
main(String[] args)
{
A a = new A();
B b = new B();
Derived derived = new Derived();
derived.method(a); /* Call 1 */
derived.method(b); /* Call 2 */
}
}
=================================
Given the language of the JLS, I'm not in any doubt (I may be /wrong/, just not
in doubt ;-) that the compiler is required to reject (Call 2) as ambiguous.
But I can't see any reason why the JLS /should/ require this to be ambiguous.
The defininition of what it is for a method to be "more specific" is (quoting
from Mike's earlier post)
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.
I cannot see a good reason for the first condition. The static influence of
the "zero-th argument" (the "this" of the method) have already been dealt with
by the previous sections about determining available and applicable candidates.
The dynamic/virtual part of a virtual method call will be dealt with by the
conditions in the next section (at runtime). So what's that clause for ? I
believe that if it were deleted, then the resulting semantics would be able to
resolve some method calls that would otherwise be ambiguous, and further that
the resolution would be entirely in accordance with intuition. (You would have
to introduce some new wording to ensure that overridden methods in superclasses
were not considered to be "available", but that is trivial).
Now, another way of getting the same semantic effect would be to consider that
every method was notionally duplicated in every class that inherited it (and
didn't override it). And that's interesting, because that notional inclusion
is also required by the binary compatibility stuff. For instance (Call 1) in
my example is /required/ to be compiled into an invocation of
Derived.method(A) even though Derived doesn't actually /have/ that method. It
is not legal for the compiler to emit bytecodes along the lines of:
invokevirtual Mid/method (LA;)V
but must use:
invokevirtual Derived/method (LA;)V
The reason I think that's relevant is that before 1.4 the Sun compilers were
emitting the (incorrect) first version. From 1.4 onwards they have been
getting it right. That's to say that the code /generation/ now implements the
"notional inclusion" of all superclass methods, and it's also since 1.4 that
the compiler has stopped rejecting (Call 2) as ambiguous.
So what I suspect has happened is that in the process of fixing the code
generation bug, it became evident that the semantics described in the JLS were
either wrong, or at least could with advantage be relaxed, and so both aspects
of the compiler now implement the same idea of what it is to inherit a virtual
method.
FWIW, the JLS3 changes appear to follow that idea. The new versions of the
relevant passages are dauntingly intricate, and I may easily be misreading
them, but it appears to me that they have dropped any mention of the type of
the primary expression, and "more specific than" is now defined only in terms
of the argument types.
-- chris
Mike Schilling
"Thomas G. Marshall" <tgm2tothe...@replacetextwithnumber.hotmail.com>
wrote in message news:LQ7Xd.48508$ya6.31174@trndny01...
> Mike Schilling coughed up:
>> "Thomas G. Marshall"
>> <tgm2tothe...@replacetextwithnumber.hotmail.com> wrote in
>> message news:TF6Xd.48451$ya6.44238@trndny01...
>>> Mike Schilling coughed up:
>
> ...[rip]...
>
>
>> [...] and the
>> implicit conversion from int to douible is treated precisely like the
>> implicit conversion from String to Object.
>
>
> No, they're not,
For the purpose of resolving method calls, they are. Look up "method
invocation conversion." in the JLS.
> but I'm re-scrutinizing the jls and I think that you're right in that
> there is a vagary here that is disturbing.
>
> This phrasing you quoted from the JLS bugs me no end:
>
> 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.
> [...]
>
> Does "method conversion" include conversion from int to double, or was
> that meant entirely as a statement concerning objects. I'm really not
> sure. I think that the jls examples were all objects.
"Method invocation conversion." is defined in 5.3, and does include
widening primitive conversions (defined in 5.1.2). Int to double is among
these.
Mike Schilling
[snip a lot of good stuff that I have no comment on]
class A { }
class B extends A { }
class Base
{
void method(B b) { System.out.println("Base(B)"); }
}
class Mid
extends Base
{
void method(A a) { System.out.println("Derived(A)"); }
}
class Derived extends Mid { }
public class Test
{
public static void
main(String[] args)
{
A a = new A();
B b = new B();
Derived derived = new Derived();
derived.method(a); /* Call 1 */
derived.method(b); /* Call 2 */
}
}
>
> FWIW, the JLS3 changes appear to follow that idea. The new versions of
> the
> relevant passages are dauntingly intricate, and I may easily be misreading
> them, but it appears to me that they have dropped any mention of the type
> of
> the primary expression, and "more specific than" is now defined only in
> terms
> of the argument types.
That's very interesting. In fact, I find that 1.3.1_08 and 1.4.1_04 report
Call 2 in your example as ambiguous (per JLS 2), where 1.4.2_01 compiles it
successfully (per your reading of JLS 3), making this quite possibly a
deliberate change (though it's not mentioned in the 1.4.2 release notes.).
Thomas G. Marshall
Ok, thanks.
By the way, there is something counter intuitive (to me, anyway). The
downcasting notion is applied in the reverse order that conversationally
sounds right, with regard to primitives. (it's not downcasting in
primitives, I'm just speaking glibly about the type coercion.)
That is, int is a specific type of double, not the other way around.
For example:
String s = new String("five");
Object o = s; // string is more specific
is akin to
int i = 5;
Double d = i; // glibly: int is more specific
--
With knowledge comes sorrow.
Thomas G. Marshall
> "Thomas G. Marshall"
> <tgm2tothe...@replacetextwithnumber.hotmail.com> wrote in
> message news:LQ7Xd.48508$ya6.31174@trndny01...
>> Mike Schilling coughed up:
>>> "Thomas G. Marshall"
>>> <tgm2tothe...@replacetextwithnumber.hotmail.com> wrote in
>>> message news:TF6Xd.48451$ya6.44238@trndny01...
>>>> Mike Schilling coughed up:
>>
>> ...[rip]...
>>
>>
>>> [...] and the
>>> implicit conversion from int to douible is treated precisely like
>>> the implicit conversion from String to Object.
>>
>>
>> No, they're not,
>
> For the purpose of resolving method calls, they are. Look up "method
> invocation conversion." in the JLS.
Ok, good point.
>> but I'm re-scrutinizing the jls and I think that you're right in that
>> there is a vagary here that is disturbing.
>>
>> This phrasing you quoted from the JLS bugs me no end:
>>
>> 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.
>> [...]
>>
>> Does "method conversion" include conversion from int to double, or
>> was that meant entirely as a statement concerning objects. I'm
>> really not sure. I think that the jls examples were all objects.
>
> "Method invocation conversion." is defined in 5.3, and does include
> widening primitive conversions (defined in 5.1.2). Int to double is
> among these.
Fair enough.
Mike Schilling
"Thomas G. Marshall" <tgm2tothe...@replacetextwithnumber.hotmail.com>
wrote in message news:7PoXd.49406$ya6.31372@trndny01...
>
> By the way, there is something counter intuitive (to me, anyway). The
> downcasting notion is applied in the reverse order that conversationally
> sounds right, with regard to primitives. (it's not downcasting in
> primitives, I'm just speaking glibly about the type coercion.)
>
> That is, int is a specific type of double, not the other way around.
>
> For example:
>
> String s = new String("five");
> Object o = s; // string is more specific
> is akin to
> int i = 5;
> Double d = i; // glibly: int is more specific
int *is* more specific:
* Every int value can be represented as a double value, but not vice versa
* A double needs to be cast to an int, but not vice versa. (Though a cast
of a non-integral-valued double truncates rather than throwing an
exception.)
Thomas G. Marshall
> "Thomas G. Marshall"
> <tgm2tothe...@replacetextwithnumber.hotmail.com> wrote in
> message news:7PoXd.49406$ya6.31372@trndny01...
>>
>> By the way, there is something counter intuitive (to me, anyway). The
>> downcasting notion is applied in the reverse order that
>> conversationally sounds right, with regard to primitives. (it's not
>> downcasting in primitives, I'm just speaking glibly about the type
>> coercion.) That is, int is a specific type of double, not the other way
>> around.
>>
>> For example:
>>
>> String s = new String("five");
>> Object o = s; // string is more specific
>> is akin to
>> int i = 5;
>> Double d = i; // glibly: int is more specific
>
> int *is* more specific:
>
> * Every int value can be represented as a double value, but not vice
> versa
That's precisely right. Every String can be represented as an Object.
Because String is more specific. An object variable can hold a string, and
not the other way around.
All int's are doubles stripped of their floating point.
Remember this is a glib conversation, but IMO you've got it backwards.
> * A double needs to be cast to an int, but not vice versa. (Though a
> cast of a non-integral-valued double truncates rather than throwing an
> exception.)
--
"It eats you starting with your bottom". Botched
translation of the demonic warning "From beneath, it
devours", in Buffy the Vampire Slayer ~2003.
Thomas G. Marshall
> Mike Schilling coughed up:
>> "Thomas G. Marshall"
>> <tgm2tothe...@replacetextwithnumber.hotmail.com> wrote in
>> message news:7PoXd.49406$ya6.31372@trndny01...
>>>
>>> By the way, there is something counter intuitive (to me, anyway).
>>> The downcasting notion is applied in the reverse order that
>>> conversationally sounds right, with regard to primitives. (it's not
>>> downcasting in primitives, I'm just speaking glibly about the type
>>> coercion.) That is, int is a specific type of double, not the other
>>> way around.
>>>
>>> For example:
>>>
>>> String s = new String("five");
>>> Object o = s; // string is more specific
>>> is akin to
>>> int i = 5;
>>> Double d = i; // glibly: int is more specific
>>
>> int *is* more specific:
>>
>> * Every int value can be represented as a double value, but not vice
>> versa
>
> That's precisely right. Every String can be represented as an Object.
> Because String is more specific. An object variable can hold a
> string, and not the other way around.
>
> All int's are doubles stripped of their floating point.
>
> Remember this is a glib conversation, but IMO you've got it backwards.
Strike this last statement. I was getting confused. Duh. We agree.
Mike Schilling
wrote in message news:PgrXd.61811$t46.17715@trndny04...
>
> All int's are doubles stripped of their floating point.
That's what makes seems backward, I think. We're used to derived classes
adding fields to their base classes, which makes double feel like a subclass
of int that adds the field "fractionalPart".
Patricia Shanahan
I think you are focussing too much on the object itself,
which is never converted and cannot be converted, rather
than on the pointer to the object. It is the pointer that
does get converted.
Think in terms of the set of things a variable can designate.
A String reference can designate any String, but not an
Integer or a HashMap. An Object reference can designate any
of those. String is more specific than Object.
An int can designate 3, or 5, or -10, but not 3.5, or
-244.125. A double can designate any of them. int is more
specific than double.
Patricia
Mike Schilling
"Patricia Shanahan" <patricia...@earthlink.net> wrote in message
news:L2sXd.4115$oO4....@newsread3.news.pas.earthlink.net...
You're right, of course. The question is why I have to work this out again
every time the question arises :-)
Lee Fesperman
> An int can designate 3, or 5, or -10, but not 3.5, or
> -244.125. A double can designate any of them. int is more
> specific than double.
Don't forget that double can represent many more integer values than int can. Loss of
precision can occur at both ends.
--
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
Thomas G. Marshall
There is a broader question, though. Is the JLS vague, or are we simply
reading it incorrectly?
--
"This creature is called a vampire. To kill it requires a stake
through its heart." "I shall drive my staff deep into its rump."
"No no, this creature is from a dimension where the heart is in the
chest." "....Disgusting."
Demons discussing "Angel", a good vampire from our dimension visiting
theirs.
Thomas G. Marshall
Yeah. But /specification/ is also used to stripping away fields, at least
conceptually:
public class SomeSquare extends SomeRectangle
{
public SomeSquare(int width) {super(width, width);}
...
}
:)
Mike Schilling
"Thomas G. Marshall" <tgm2tothe...@replacetextwithnumber.hotmail.com>
wrote in message news:nfsXd.63844$W16.40044@trndny07...
>
>
> There is a broader question, though. Is the JLS vague, or are we simply
> reading it incorrectly?
Neither. I suspect that Chris Uppal has the right of it: the defined
behavior in this case has changed between JLS 2 and JLS 3. We all,
correctly, read JLS 2 as considering these calls ambiguous. Chris reads JLS
3 as considering them unambiguous (I don't have JLS 3 available, but I'll
take his word for it.) This is consistent with the fact that javac 1.4.1
and earlier give "ambiguous call" errors, while 1.4.2 and later do not.
I'd love to see a release note or some other communication from Sun
confirming this, of course.
Chris Uppal
> [...] 1.4.1_04
> report Call 2 in your example as ambiguous (per JLS 2), where 1.4.2_01
> compiles it successfully (per your reading of JLS 3),
Ah well, that blows my bug-fix theory out of the water. I've just found a
1.4.1 compiler that (as you say) rejects the call as ambiguous, but doesn't
suffer from the code-generation bug.
So whatever the story really is here, the change isn't any sort of side effect
of fixing that bug.
I'm still hopeful that the change was deliberate (and so won't be backed out)
since the new behaviour makes a lot more sense to me. Helluva big change for a
dot-dot release, though...
-- chris
Chris Uppal
> Chris reads
> JLS 3 as considering them unambiguous (I don't have JLS 3 available, but
> I'll take his word for it.)
Neither do I have it. The nearest thing I have, and what I was referring to,
is:
http://java.sun.com/docs/books/jls/jls-proposed-changes.html
I should have been more explicit about the status of the doc. I was referring
to in my earlier post, sorry.
-- chris
Mike Schilling
I don't know how to read this, to be honest. Here's the definition of more
specific:
One fixed-arity member method named m is more specific than another member
method of the same name and arity if all of the following conditions hold:
* The declared types of the parameters of the first member method are T1,
..., Tn.
* The declared types of the parameters of the other method are U1, . . . ,
Un.
* If the second method is generic then let S1, .., Sn be the types inferred
(ยง15.12.2.7) for its parameters under the initial constraints Ti << Ui
otherwise let . Then, for all j from 1 to n , Tj <: Sj .
Reading this literally, if the second method is not generic, the first is
*always* more specific, since no conditions for being more specific are
defined.