Community
Participate
Working Groups
I20030628++ Test case: class A { private void foo() {} } class B extends A { private void foo() {} } Searching for declarations in hierarchy of A.foo() returns B.foo() which from a language point of view isn't correct. However it makes sense from a user's point of view. The search engine should offer a flag to control whether the client or the language point of view is requested.
it's a defect with a long history - see bug 3615 and bug 3619 i'll close bug 3615 as a dup of this one
*** Bug 3615 has been marked as a duplicate of this bug. ***
Strictly speaking, the search is finding all declarations matching a signature, within a type hierarchy. Thus it is doing the right thing. Now, the override indicator should not be positionned for private methods or default ones across package boundaries, since these aren't seeing each other.
Ok to close?
Now, since for refactoring we need a way to find out if a method really overrides another method. We can trun this one into a feature request.
FYI: this bug made me put a rather nasty workaround to fix bug 40767
I'd rather keep the current behavior which allows to find related methods (even non visible). Closing
Philippe, would it be possible to provide API that gives us the desired behaviour. Currently we have to put in the logic what "overrides" means. This is IMO core knowhow.
At an API level, IMethod#isOverriding(IMethod) would be quite inefficient since it would need to check first whether the arg method is in the hierarchy of the first one... would be highly inefficient given your usecase.
So, what do you recommend to solve the issue <g>
If it is in the DOM then this is a separate problem.
No it isn't in the DOM. We use "search declaration in hierarchy" and want a language conform result set.
Refactoring is only a particular usecase where you would like to play certain rules. I think in general searching for related declarations is a useful query. Think for instance that looking for static methods or fields would never provide more than one hit when starting from an element... You would need a slightly different query I believe.
I am not trying to say that the current query isn't useful. All we need is a language conformant counterpart of that query. Can we write one by ourselves ?
