Forums Register Login

overloaded methods

+Pie Number of slices to send: Send
Just in case anyone has not seen this one:

(Added new B(). Thanks Lih.)
[ April 16, 2003: Message edited by: Marlene Miller ]
+Pie Number of slices to send: Send
 

Originally posted by Marlene Miller:
Just in case anyone has not seen this one:

[ April 16, 2003: Message edited by: Marlene Miller ]


I added new B() in front of the method call. I'm not sure this was what you meant. What's intresting is that if I changed both methods to static, there is no compiler error and prints out 'char'. Don't know exactly why?
+Pie Number of slices to send: Send
Could this be the reason that static method does not participate polymorphism in the class hierarchy? But, why doesn't the compiler convert 'x' to int if both methods were declared as static?
+Pie Number of slices to send: Send
Swap m(char c) and m(float f) and B compiles cleanly.
Move m(char c) out of A and put it in B and B compiles cleanly.
Make all the m()'s static and it compiles cleanly.
What do you think is happening in Marlene's little problem?
+Pie Number of slices to send: Send
Too many questions and too much confusion - that's why I'm still learning. Thomas, could you please tell me why? Thanks.
+Pie Number of slices to send: Send
I have tried several other combinations.

Based on what I got, I guess that the compiler will choose the most compatible method and find the method from the bottom up in class hierarchy. Hope someone can shed some light on this.
+Pie Number of slices to send: Send
Lih, you've been working hard on this one. This example helped me alot. I hope it helps you too.
Since the type of the argument in the m(�x�) is char, both m(float f) and m(char c) are *applicable* to the method invocation.
For the compiler to choose m(char c) instead of m(float f), (1) char has to be assignment compatible with float and (2) the class where m(char c) is declared has to be assignment compatible with the class where m(float f) is declared.
Unfortunately, a value of type A cannot be converted to B.
For the compiler to choose m(float f) instead of m(char c), (1) float has to be assignment compatible with char and (2) the class where m(float f) is declared has to be assignment compatible with the class where m(char c) is declared.
Unfortunately, a value of type float cannot be converted to char.
So the method invocation m(�c�) is ambiguous.
+Pie Number of slices to send: Send
Well done, Marlene. Trying to figure that out from the JLS can be very painful and this little example helps to explain it easier.
+Pie Number of slices to send: Send
Marlene says:

Since the type of the argument in the m(�x�) is char, both m(float f) and m(char c) are *applicable* to the method invocation.
For the compiler to choose m(char c) instead of m(float f), (1) char has to be assignment compatible with float and (2) the class where m(char c) is declared has to be assignment compatible with the class where m(float f) is declared.
Unfortunately, a value of type A cannot be converted to B.


The JLS says that if more than 1 method applies to the argument, the most restrictive method is chosen.
In this case method char m(char c) in base class A is more restrictive than method float m(float f) in subclass B.
Based on this rule I would expect the compiler to choose the method in base A.
But the compiler gives an error message, so something else is going on.
When both methods are static or in the same class, there is no problem.
If one method is inherited and an other method overloads the base method, the order does matter.
Why is this?
+Pie Number of slices to send: Send
Hi John, I am glad you asked that question. This example helps to debug our assumptions.
The compiler chooses one method declaration m instead of other overloaded method declarations m� because
(1) all the types of the parameters of m can be converted to the types of the parameters of m�.
(2) the class where m is declared can be converted to the class where m� is declared.
Given
m(char c) declared in class A
m(float f) declared in class B
Can we convert char to float? Yes. Can we convert A to B? No.
Can we convert float to char? No. Can we convert B to A? Yes.
Here is the official description: JLS 15.12.2.2
+Pie Number of slices to send: Send
Thank you Thomas. Painful is right. I learned this example from the SUN forums. I watched people puzzle over this for pages and pages.
I wish I had such revealing examples for every single item in the JLS. I even suggested a SUN forum called the "anotated JLS" where people could post examples and insights.
+Pie Number of slices to send: Send
Marlene, thank you so much for sharing your thought. I think I need to spend more time reading JLS before posting anymore. Thanks again. Here I wrote three more examples with some explanation just to make sure I understood the concept. I used the word "see" in my comment, not sure it is right though. If I was wrong again or missed any critical concept, please correct me. Thanks in advance.

[ April 17, 2003: Message edited by: Lih Wang ]
+Pie Number of slices to send: Send
 

Originally posted by Marlene Miller:
I even suggested a SUN forum called the "anotated JLS" where people could post examples and insights.

Have you read the book, "Java Rules"?
+Pie Number of slices to send: Send
 

Originally posted by Marlene Miller:
I wish I had such revealing examples for every single item in the JLS. I even suggested a SUN forum called the "anotated JLS" where people could post examples and insights.


Howdy
I just want to be REALLY clear that this level of understanding and clarity about the spec is FAR beyond what is required for the exam. I'm by no means trying to disuade you from the attempt, Marlene (and others), because the more we all know the better -- and because I think that your original quote about "the more I understand..." couldn't be more right.
My concern is that a lot of the discussions on this cert forum lately have been way WAY beyond the scope of the exam, and I think that this might be intimidating to folks who aren't -- or don't want to be -- that intimate with the spec
And at Sun we believe that you don't *need* to be that intimate, in order to pass the exam, and in order to be a really good Java programmer.
In fact, we think most folks could learn exactly what they need to learn *without* referring to the spec, although it certainly doesn't hurt. We believe folks will be better off if they spend their time learning patterns, idioms, and key APIs in general, but we can't test for that in SCJP because there was not a standard agreement on exactly WHICH of those should be required for ALL Java programmers. In the early days, for example, I/O and AWT were considered essential for any Java programmer. But the surge in server-side development eventually drove us to finally drop those two objectives for the 1.4, as more and more developers were doing back-end work (no GUI), where the application servers handle the I/O.
So my comment to everyone out there prepping is to "pick your battles" for the purposes of the exam.
By all means, continue to do whatever other research and discovery and experimenting and learning that you can and want to do, but understand that you may be going way beyond what is required knowledge, understanding, and memorization for the exam. But please know, that with only limited brain resources, going too far beyond what's needed for the exam could hurt -- or at least delay -- your ability to adequately prepare for the exam.
Cheers,
Kathy (who herself has extremely limited brain resources
p.s. although I realize that there is much debate on whether it is appropriate for someone to pass the exam without having practical Java knowledge; that's not what I'm talking about here. On a Venn diagram, practical knowledge and spec knowledge overlap in only *some* areas. As I suggested, intense spec-knowledge sure could not hurt, but it definitely is not a requirement for either the exam OR becoming a good, practical Java programmer. We consider it a matter of personal preference. Some folks like to read and study and understand specs, and some don't. And the JLS is *not* a reader-friendly spec. An important document, sure, and the one you want to rely on when there is a dispute, but by no means is it a document we believe all Java programmers must read.
On the other hand, some of the other Java specs *are* useful and readable. The EJB spec, for example, is inherently usable, and absolutely crucial for an EJB developer. But that's a different kind of spec...
Self destruct mode activated. Instructions for deactivation encoded in this tiny ad.
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 1020 times.
Similar Threads
Overloading problem
Java/JBuilder - Anyone with brains please help
Override issue
primitive widening doubt
Name Hiding
Thread Boost feature
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 19:30:45.