|
|
|
|
| Re: call hierarchy of overridden method [message #631697 is a reply to message #631677] |
Fri, 08 October 2010 13:54   |
 Luis 
Messages: 5
Registered: October 2010 |
Junior Member |
|
|
OK, it's not from every class, but it's still finding equals methods from super classes. Since I'm overriding this method, I don't consider it the same method and I there should be a way to find all appearances of this only one method.
If B extends A, and A overrides equals but B doesn't, I open B, select the equals word of its equal method, select References -> Project It should appear every call to equals method from instances of A and B (since B is inheriting this method from A, it's the same method).
But, if we override this method in B too, and I open B, select the equals word of its equal method, select References -> Project, it should appear ONLY calls to equals method from instances of B. It's overridden, so it's a very different method.
Am I wrong?
Thanks!
Luis
|
|
|
| Re: call hierarchy of overridden method [message #631756 is a reply to message #631697] |
Fri, 08 October 2010 15:23 |
Eclipse User |
|
|
|
Originally posted by: richkulp.us.NOSPAM.ibm.com
Hi,
It's overridden, BUT, that explicit method can still be called from a
class that has an instance of type B set into a variable typed as A.
Because of this those classes can still call this method on B even
though they think it is an A. There is no way for JDT to know that such
a variable of type A would never ever contain an instance of type B.
That is a runtime question and not a static compile time analysis problem.
On 10/8/2010 9:54 AM, Luis wrote:
>
> But, if we override this method in B too, and I open B, select the
> equals word of its equal method, select References -> Project, it should
> appear ONLY calls to equals method from instances of B. It's overridden,
> so it's a very different method.
--
Thanks,
Rich Kulp
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04277 seconds
] 
Search
Help
Register
Login
Home
