| impossible to refactor/reference/etc toString() method [message #256903] |
Mon, 13 October 2008 10:58  |
Eclipse User |
|
|
|
Originally posted by: Michiel.Kamermans.icis.decis.nl
Hi,
I'm using Eclipse 3.4. 0 and noticed today that the method referencing system
seems to do something odd for at least the toString method, but several other
methods that are inherited from Object too. Let's say I have a class MyClass
with a toString method:
public class MyClass { public String toString() { return super.toString(); }
}
then there are several things I cannot do to this toString() method that I
should reasonably be able to do...
For one, if I call this toString() anywhere in my code, I will not be able to
check where I do this: right clicking on the method name, selecting
"references" and then picking any of the options will have eclipse look for
*all* <? extends Object>.toString() calls, instead of only MyClass.toString()
calls. Presumably because of this quirk, I also cannot refactor this method,
as doing so tries to modify the Object.toString() method as well.
Is there a way to tell eclipse not to do whatever deep probing it's doing to
determine that MyClass.toString() is "really" Object.toString(), when I
intentionally leave off the eclipse keyword "@Override"? I've left it off
because I assumed that way eclipse will flag that my method has the same
signature, generating a quickjump to that super method, but won't consider
the two actually linked for the purpose of IDE operations.
- Mike Kamermans
Thales Research and Technology, Delft, the Netherlands
|
|
|
| Re: impossible to refactor/reference/etc toString() method [message #256907 is a reply to message #256903] |
Mon, 13 October 2008 14:41  |
| Eclipse User |
|
|
|
Originally posted by: wegener.cboenospam.com
Mike Kamermans wrote:
> Hi,
>
> I'm using Eclipse 3.4. 0 and noticed today that the method referencing system
> seems to do something odd for at least the toString method, but several other
> methods that are inherited from Object too. Let's say I have a class MyClass
> with a toString method:
>
> public class MyClass { public String toString() { return super.toString(); }
> }
>
> then there are several things I cannot do to this toString() method that I
> should reasonably be able to do...
>
> For one, if I call this toString() anywhere in my code, I will not be able to
> check where I do this: right clicking on the method name, selecting
> "references" and then picking any of the options will have eclipse look for
> *all* <? extends Object>.toString() calls, instead of only MyClass.toString()
This isn't what I'm seeing. Eclipse only identifies references to
MyClass.toString() or Object.toString(). If there is a MyOtherClass
that overrides the toString() method, it isn't returned in a reference
search for MyClass.toString(). This isn't all that odd. The Eclipse
compiler can't determine what a given Object reference in your code will
actually point to at run time. It is possible that the reference will
be an instance of MyClass.
> calls. Presumably because of this quirk, I also cannot refactor this method,
> as doing so tries to modify the Object.toString() method as well.
>
The problem here is the ambiguity of what it means to refactor an
overridden method. Which toString references (or possible references)
to MyClass do you want to change? After a refactor, MyClass will still
have implementations of both methods, the original and the new.
Presumably, Both methods would be valid depending on the callers intent.
What would you expect the refactor process to do in such a situation?
> Is there a way to tell eclipse not to do whatever deep probing it's doing to
> determine that MyClass.toString() is "really" Object.toString(), when I
> intentionally leave off the eclipse keyword "@Override"? I've left it off
> because I assumed that way eclipse will flag that my method has the same
> signature, generating a quickjump to that super method, but won't consider
> the two actually linked for the purpose of IDE operations.
>
> - Mike Kamermans
> Thales Research and Technology, Delft, the Netherlands
|
|
|
| Re: impossible to refactor/reference/etc toString() method [message #256927 is a reply to message #256903] |
Tue, 14 October 2008 09:15 |
| Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
Mike Kamermans wrote:
> Is there a way to tell eclipse not to do whatever deep probing it's doing to
> determine that MyClass.toString() is "really" Object.toString(), when I
> intentionally leave off the eclipse keyword "@Override"? I've left it off
> because I assumed that way eclipse will flag that my method has the same
> signature, generating a quickjump to that super method, but won't consider
> the two actually linked for the purpose of IDE operations.
The @override annotation is not a special signal to Eclipse as you
assume; it is a standard Java annotation. Read about it here:
http://www.java-tips.org/java-se-tips/java.lang/introducing- annotations.html
Eric
|
|
|
Powered by
FUDForum. Page generated in 0.04767 seconds
Home